AD  -  A  1 22  360  GRAPES  USER'S  MANUAL(U)  CARNEGI E -MELLON  UNIV  PITTSBURGH 
PA  DEPT  OF  PSYCHOLOGY  R  SAUERS  ET  AL .  NOV  82  ONR-82-3 
N00014 -81 -C-0335 


UNCLASSIFIED 


F/G  9/2 


microcopy  resolution  test 


GRAPES 


User’s  Manual 


Ron  Sauers 
Dept,  of  Mathematics 
Carnegie- Mellon  University 

Robert  Farrell 
Department  of  Psychology 
Carncgic-Mcilon  University 

November  1982 


Approved  for  public  release;  distribution  unlimited. 
Reproduction  in  whole  or  part  is  permitted  for  any  purpose 
of  die  United  States  government 


This  research  was  supported  by  die  Personnel  and  Training  Research  Programs.  Psychological  Services 
Division.  Office  of  Naval  Research,  under  Contract  No.:  N00G14-81-C-0335.  Contract  Authority 
Identification  Number,  NR  No.;  157-465  to  John  Anderson. 


8*  12  18 


\y  v»‘  '<J 


.'l 


SECURlTv  CLASSIFICATION  of  This  page  0,1,  Enter'd. 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1  REPORT  NUMBER  j2.  GOVT  ACCESSION  NO. 

3.  RECIPIENT’S  CATALOG  NUMBER 

4.  TITLE  ("and  Subtitle) 

5.  TYPE  OF  REPORT  A  PERIOD  COVERED 

GRAPES  User's  Manual 

Interim  report 

6.  performing  org.  report  number 

1  ‘UThORflJ 

8.  CONTRACT  OR  grant  NUMBERfiJ 

Ron  Sauers 

Robert  Farrell 

N00014-81-C-0335 

9.  PERFORMING  ORGANIZATION  NAME  ANO  AOORESS 

Department  of  Psychology 
Carnegie-Mellon  University 
Pittsburgh,  PA  15213 


II.  controlling  office  NAME  ANO  AOORESS 

Personnel  and  Training  Research  Programs 
Office  of  Naval  Research 

Arlington,  VA  "2221?  '  _ 


14.  MONITORING  agency  name  ft  AOORESS^//  different  from  Controlling  Office)  15 


12.  report  date 

November  30,  1982 


15.  SECURITY  CLASS.  (Of  thte  report) 


1S«.  DECLASSIFICATION  DOWNGRADING 
SCHEDULE 


i6.  Distribution  st atemen t  (of  this  Report) 

Approved  for  public  release;  distribution  unlimited 


17.  DISTRIBUTION  ST  atemen  T  (of  the  abetract  entered  in  Block  20,  If  different  from  Report) 


19.  KEY  WORDS  (Continue  on  reverae  aide  it  necesaery  and  identify  by  block  number) 

production  system  composition  planning  compilation 

programming  language  pattern  matching  automatic  programming  data-flow 

LISP  working  memory  cognitive 

goal  structure  interpreter  computer 

procedural! cation _ modelling  learning 


20.  ABSTRACT  (Continue  on  reverae  aide  If  neceaaery  end  Identify  by  block  number) 

GRAPES  is  a  goal-restricted  production  system  designed  for  modeling 
human  cognitive  processes.  The  system's  declarative  knowledge  resides  in  a 
dynamic  working  memory  and  its  procedural  knowledge  is  embodied  in  condition- 
action  rules  known  as  productions.  Each  production  can  apply  only  in 
reference  to  the  current  goal.  The  goals  are  organized  in  an  and/or  tree  with 
the  root  node  being  the  top  goal,  which  is  specified  by  the  user.  The  tree  is 
explored  in  a  left-to-right ,  depth-first  manner.  Features  of  the  language _ 


DO  ,  :°r7]  1473  EDITION  OF  1  NOV  65  IS  OBSOLETE 


5ECU1ITV  CLASSIFICATION  OF  THIS  PAGE  fWh»n  0,1,  En(«r»d> 


SECURITY  CLASSIFICATION  OF  This  PAOerWTun  D*t*  Ent»r»d) 


20.  Abstract  (cont) 

include  goal  parameter  specification,  flexible  goal  matching,  LISP  function 
calls  within  production  rules,  and  a  host  of  user-acessible  functions 
designed  for  their  powerful  matching  ability.  The  interpreter  includes 
an  interrupt  capability,  a  photo  package,  a  tracing  mechanism,  and 
various  debugging  facilities.  One  peripheral  module  contains  procedural- 
i cation  and  composition,  two  learning  mechanisms  used  to  acquire  new 
productions.  Another  module  contains  useful  functions  for  modelling  LISP 
programmers.  GRAPES  is  best-suited  for  highly  goal-directed  tasks  involving 
planning  or  problem  solving. 


SECURITY  CL  »S*iriC*TlO»  of  T“"-  PAGEO*? >an  Cat*  Entrrrdl 


L. 


Table  of  Contents 


i 


1 .  Introduction 

2.  Working  Memory 

3.  The  Goal  Structure 

3.1.  Goal  Format 

3.2.  Creating  an  And-Or  Tree 

4.  The  Production  Set 


4.1.  Production  Format 

4.2.  The  Left-Hand  Side 

4.2.1.  Pattern  Matching 

4.2. 1.1.  Constant  Patterns 

4.2. 1.2.  Variable  Patterns 

4.2. 1.3.  Variable  landings 

4.2. 1.4.  String  Variables 

4. 2. 1.5.  Patterns  Returned  from  Functions 

4.2.2.  Production  Parameters 

4.2.3.  Working  Memory  Tests 

4.2.4.  Goal  Tests 

4.2.4. 1.  Nested  Goal  Tests 

4.2.4.2.  Goal  Test  Parameters 

4.2.5.  Left-Hand  Side  Function  Calls 

4.2.6.  Negative  Tests 

4.2.7.  Partial  Matching 

4.3.  The  Right-Hand  Side 

4.3.1.  Additions  to  Working  Memory 

4.3.2.  Additions  to  Goal  Memory 

4.3.3.  Right-Hand  Side  Function  Calls 


5.  The  Recognize-Act  Cycle 

5.1.  Finding  the  Current  Goal 

5.2.  Matching  -  Determining  the  Conflict  Set 

5.3.  Conflict  Resolution 

5.3.1.  Action  Specification 

5.3.2.  Refraction 

5.3.3.  Recency 

5.3.4.  Specificity 

5.3.5.  Randomness 

5.4.  Firing  a  Production  Instantiation 

5.5.  Continued  Processing 


1 

3 

5 

5 

6 
9 

9 

10 
10 
10 
11 
11 
12 
13 

13 

14 

14 

15 

15 

16 
16 
17 

17 

18 
18 
19 
21 
21 
22 
22 
22 
23 
23 

23 

24 
24 
24 


6.  User  Functions  25 

6.1.  General  Functions  25 

6.2. 1  eft-1  land  Side  (  unctions  27 

6.2.  Right-Hand  Side  Functions  28 

6.4.  About  Function  Calls  in  GRAPHS  31 

6.4.1.  Calls  to  Common  I.ISP  Functions  31 

6.4.2.  Defining  Your  Own  Functions  32 

7.  Using  the  Interpreter  33 

7.1.  Defining  the  System  33 

7.2.  Starting  and  Stopping  the  System  35 

7.3.  Resuming  the  System  36 

7.4.  Printing  Useful  Information  37 

8.  Debugging  39 

8.1.  About  die  Monitor  and  QUIF.T  Mode  39 

8.2.  Breaking  39 

8.3.  GRAPHS  Debugging  Commands  40 

9.  Special  Packages  41 

9.1.  fracing  and  Breaking  41 

9.1.1.  Starting  the  Trace  41 

9.1.2.  Stopping  the  Trace  43 

9.1.3.  Trace  Switches  44 

9.2.  Photo  45 

10.  Learning  Mechanisms  47 

10.1.  Proceduralization  47 

10.1.1.  Interpretive  Productions  47 

10.1.2.  Finding  What  to  Proccduralize  48 

10.1.3.  Forming  Special  Case  Rules  48 

10.1.4.  Production  Strength  48 

10.2.  Composition  48 

10.2.1.  When  to  Compose  49 

10.2.2.  Where  to  Start  49 

10.2.3.  Where  to  Find  49 

10.2.4.  The  Composed  Left-Hand  Side  49 

10.2.5.  The  Composed  Right-Hand  Side  50 

10.2.6.  Changes  in  the  Production  Appearance  50 

10.3.  An  example  of  learning  51 

Appendix  I.  Summary  of  System  Commands  57 


1 


! 


] 

i 


Appendix  II.  Summary  of  User  Functions 
Appendix  III.  New  Functions  and  Changes 
Appendix  IV.  User-Accessible  Parameters 
Appendix  V.  A  Sample  Production  Set 
Appendix  VI.  A  Sample  Run 
Appendix  VII.  The  LISP  Module 
VI  1.1.  Top-lcvcl  commands 
VI (.2.  User  Functions 
Vll.3.  A  Sample  Symbol  Table 
Appendix  VIII.  Formal  Production  Specification 


1 


1 .  Introduction 

GRAPHS  is  .in  interpreter  for  a  Goal-Restricted  Production  System  language.  This  document  is  intended 
to  allow  the  user  to  create  and  use  GRAI’I  S  program  environments  in  order  to  accomplish  goal-directed 
tasks.  The  GRAPHS  interpreter  is  built  on  top  of  a  I  ran/  I. ISP  environment  and  therefore  a  basic  familiarity 
with  some  dialect  of  I  ISP  is  assumed.  Prev  ions  knowledge  of  a  production  system  language  (such  as  OPS5)  is 
helpful,  but  not  essential. 

Users  of  the  GRAPHS  interpreter  do  not  really  write  programs:  instead,  they  must  create  program 
environments.  A  GRAPHS  program  environment  consists  of  three  major  pieces.  These  are: 

Working  Memory  This  part  of  the  program  environment  holds  what,  in  most  high-level  programming 
languages,  would  be  considered  program  data. 

A  Goal  Structure  This  provides  a  great  deal  of  the  control  structure  within  the  program  environment,  and  is 
basically  a  means  of  letting  the  system  know  what  tasks  it  is  supposed  to  accomplish. 

A  Production  Set  Phis  part  of  die  environment  is  the  part  which  most  people  would  recogni/c  as  doing  most 
of  the  work  while  the  system  is  running.  Kach  production  in  the  production  set  is  a 
miniature  program  which  can  test  against  and  operate  on  working  memory  and  die  goal 
structure  while  the  GRAPHS  system  is  running. 

Although  the  three  pieces  of  the  GRAPHS  program  environment  are  dependent  on  each  other,  each  is  a 
separate  entity.  Hor  diis  reason,  each  of  the  pieces’  w  ill  be  described  in  its  ow  n  section  within  this  document 
Section  two  describes  the  working  memory  structure,  section  dircc  describes  die  goal  structure,  and  section 
four  describes  the  GRAPHS  production  set.  Section  five  describes  the  rccognizc-uct  cycle,  including 
GRAPFS’s  conflict  resolution  strategics.  Then,  in  part  six.  a  section  is  devoted  to  a  special  set  of  functions 
designed  to  allow  the  user  to  write  GRAPES  productions  more  easily.  Section  seven  describes  how  to  use  the 
GRAPHS  interpreter  in  order  to  execute  a  program  environment.  Section  eight  is  devoted  to  the  GRAPES 
debugging  mechanisms.  In  section  nine  three  special  i/o  packages  arc  introduced.  Finally,  in  section  ten,  the 
GRAPES  learning  mechanisms  arc  explained.  A  sample  run  and  a  glossary  of  commands  can  be  found  in  the 
appendices,  as  well  as  a  syntactic  specification  of  GRAPES  productions. 


2.  Working  Memory 

Working  memory  is  ihal  part  of  the  GRAPHS  program  environment  which  stores  data  elements.  The  user 
may  initialize  working  memory  so  that  it  contains  some  data  at  the  start  of  system  execution1  .  Also,  data 
items  may  be  inserted  or  deleted  during  system  execution. 

Kach  data  item  in  working  memory  is  called  a  working  memory  element.  Hath  working  memory  element  is 
a  list  structure" .  and  can  have  an  arbitrary  length  and  complexity.  For  example,  the  following  structure  is  a 

legal  GRAPHS  working  memory  element: 

(IF  1 istl  HAS-RELATIONSHIP  relatlonl  TO  (11st2) 

THEN  either  (llstl  HAS-RELATIONSHIP  relat1on2  TO  (11st2)) 

OR  ((llstl  HAS-RELATIONSHIP  rel»t1on2  TO  (11st3)) 

ANO 

( 1  1  s 1 3  HAS-RELATIONSHIP  relatlonl  TO  (11st2)))) 

However,  working  memory  elements  can  be  much  simpler.  For  example,  this  is  also  a  legal  working 

memory  element: 

(IS-A  argumentl  ATOM) 

The  following  arc  not  legal  working  memory  elements: 

worklng-memory-element  ;  Not  a  list. 

(IS-A  (Iteml)  a  (list)))  ;  Unmatched  parenthesis. 

Thus,  it  can  be  seen  that  fairly  complicated  data  structures  can  be  represented  in  working  memory.  The 
most  important  constraint  is  that  working  memory  elements  should  contain  information  which  is  relevant  to 
the  task  at  hand.  Also,  the  user  may  want  to  adopt  some  kind  of  convention  in  forming  working  memory 
elements,  since  this  helps  in  writing  production  sets  which  work  properly.  For  example,  some  conventions 
which  might  be  used  are: 

(HAS-RELATIONSHIP  <Uatnl>  <relat1onsh1p>  (  <1 1st-of-1tems>  )) 

or 

(IS-A  <1tam>  <typa>  ) 


1 

see  section  seven 

^in  the  sense  of  a  I.ISP  list  structure 


5 


3.  The  Goal  Structure 

The  GRATIS  goal  simcmre  is  th.it  pan  of  the  program  einironmciu  which  tells  the  s>stem  what  tasks  it  is 
supposed  to  he  accomplishing  at  am  given  time.  I  he  user  must  start  the  s\ stem  off  with  an  initial  goal,  called 
the  lo/t-goal.  I  lie  main  objective  of  the  system  is  to  succeed  with  the  top-goal:  once  the  top-goal  is  successful, 
the  system  stops  running. 

As  die  system  runs,  more  goals  arc  created  and  inserted  into  the  goal  lice.  Tor  example,  a  goal  (let  us  call  it 
goal-1)  may  get  inserted  as  a  subgoal  of  the  top-goal,  and  then  two  other  goals  (goal-2  and  goal-3)  may 
become  subgoals  of  goal-1,  etc.  As  each  new  goal  is  inserted  into  die  goal  tree,  the  system  tries  to  accomplish 
that  goal.  This  process  continues  until  die  system  finds  a  goal  which  it  can  solve:  dns  goal  becomes  successful. 
A  goal  is  successful  w  hen  a  production  explicitly  declares  it  to  be  successful'5 .  or  when  all  of  its  subgoals  have 
been  successful. 

At  the  beginning  of  each  cycle.  GRAPHS  docs  a  depdi-first  search  on  the  goal  tree,  looking  for  a  goal 
w  hich  has  not  already  been  successful.  If  there  is  no  such  goal4 .  then  the  system  stops,  hav  ing  accomplished 
its  top-goal.  Otherwise,  the  resulting  goal  is  declared  to  be  the  current-goal.  When  the  system  first  begins  to 
run.  the  top-goal  automatically  becomes  the  current-goal. 

Thus,  at  all  times,  the  system  is  operating  in  the  context  of  a  current-goal.  This  goal  is  important,  since  all 
productions  must  fire  in  the  context  of  the  current-goal.  The  user  will  find  that  diis  gives  the  system  a 
well-defined  control  structure,  while  still  retaining  the  flexibility  of  other  production  system  languages. 

3.1.  Goal  Format 

All  goals  are  specified  by  a  set  of  parametcrs.cach  of  which  is  an  attributc/valuc  pair.  Each  attribute  must 
be  an  atom  ending  in  the  character  Values. may  be  any  legal  symbolic  expression.  There  is  no  restriction 
on  the  number  of  parameters  which  a  goal  may  have,  or  on  the  names  of  die  attributes,  except  that  every  legal 
goal  must  have  an  "action:"  attribute. 

For  example,  die  following  is  a  legal  format  for  describing  the  top-goal: 

(top-goal 

(action:  wrlta-functlon 
name:  functlonl 
arguments:  (argl  arg2  arg3) 
output:  resultl)  ) 


5 sec  section  six 

4 

that  is.  if  every  goal  in  the  tree  has  been  successful 
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In  this  example,  the  "action:"  of  the  top-goal  is  "write-function".  The  other  attributes  defined  for  the 
top-goal  are  "name:",  "arguments:",  and  "output:".  Note  that  values  given  to  attributes  can  be  either  atoms 
or  lists. 

The  following  examples  arc  not  legal  descriptions  for  a  goal: 

(top-goal 

(object:  goal-1 

argument:  argl)  )  ;  This  goal  has  no  action:. 

(top-goal 

(action:  some-action  ;  "argument1*  Is  not  a  legal 

argument  argl)  )  :  attribute-  there  Is  no 

3.2.  Creating  an  And-Or  Tree 

flic  goal  tree  that  the  system  constants  is.  by  default,  an  ami  tree,  Fach  branch  must  be  executed  in  a  left 
to  right  manner.  An  or  branch  can  be  achieved  by  firing  a  production  at  a  goal  which  failed,  or  through  the 
use  of  the  *rcdo  command.  If  cither  of  these  techniques  is  used,  the  given  goal  will  be  an  or  branch,  and  the 
state  of  the  goal  tree  will  be  preserved  while  the  new  goal  is  inserted. 

For  example,  if  the  goal  tree  is: 

top-goal 

goal-1 
.  and 

goal-2  goal-3 

and  we  did  a  (’redo  goal-1)  then  goal-1  would  become  an  active  goal.  If  a  production  fired  at  goal-1  and 
inserted  a  new  subgoal,  goal-4,  then  the  goal  tree  would  look  like  this: 

top-goal 

goal-1 

.  and  or  . 
goal-2  goal-3  goal-4 

where  goal-4  is  now  an  or  branch  and  will  be  the  only  subgoal  recognized  be  the  interpreter.  Future 
implementations  make  make  use  of  the  old  goal  information5.  Or  branches  can  also  be  made  when  a  goal  fails 
and  another  production  fires  at  the  goal.  At  each  failure,  the  system  will  try  to  find  any  applicable 

Attached  to  goal-2  and  goal- 3  in  the  example 
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productions,  but  if  no  such  productions  arc  found,  the  failure  will  continue  up  the  tree  to  the  top  goal. 

Productions  can  match  against  a  goal  or  a  block  of  goals.  anywhere  in  the  goal  tree.  In  addition,  goals  can 
he  inserted  at  any  place  in  the  tree,  one  at  a  tune  or  as  a  whole  unit.  This  goes  the  ilexibiiity  needed  for 
modelling  highly  demanding  cognitive  tasks,  where  subjects  do  not  necessarily  follow  a  strict  depth-first 
search  strategy.  See  section  4  for  a  more  detailed  description  of  goal  matching. 


4.  The  Production  Set 

I  he  GR AIM  S  production  sot  is  the  part  of  the  program  environment  which  tells  the  vystem  when  and  how 
the  rest  of  the  program  environment  may  change,  l-ach  production  in  the  production  set  is  in  itself  a 
miniature  program  description. 


4.1.  Production  Format 

Hach  production  has  two  major  portions.  Hie  first  piece  is  called  the  left-hand  side  of  die  production,  and  is 
basically  a  description  of  the  conditions  which  must  be  true  in  the  GRAPHS  environment  in  order  for  that 
production  to  fire.  The  other  piece,  called  die  right- hand  side  of  the  production,  is  a  description  of  what 
actions  are  to  be  taken  when  that  production  tires. 


Productions  arc  defined  using  die  GRAPHS  function  p.  The  two  halves  of  the  production  arc  separated  by 
the  symbol  =  =>.  .Also,  each  production  must  be  given  a  unique  name,  which  must  be  a  non-nil  atom  having 
no  Franz  LISP  function  definition.  Thus,  die  syntax  for  a  production  definition  is: 

(p  <product1on-name> 

<lef t-hand-slde) 

•  *> 

<r1ght-hand-s1de>  ). 


Or  more  specifically: 

(p  <product1on-name> 
action:  <value> 

[  kother  parameters)  ] 

[  <tests:>  [  <worMng-memory  tests)  ] 
[  <goa1  tests)  ] 

[  kfunctlon  calls)  ] 

] 

[  kworklng  memory  additions)  ] 

[  <goal  tree  additions  >  ] 

[  Cfunctlon  calls)  ] 

) 


The  remainder  of  this  section  describes  in  detail  die  formats  of  each  of  die  sections  of  a  production.  For  a 
precise  syntactic  specification  for  GRAPES  productions,  see  appendix  eight. 
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4.2.  The  Left-Hand  Side 

I  lie  lelili.md  side  is  ih.it  p.nt  of  .1  production  lm.ii  J-  jibes  the  conditions  which  must  he  true  m  the 
GRAPHS  program  environment  in  order  for  th.it  pioductmn  to  the.  I  he  left  h.iiui  side  of.i  pioduetton  ulw.i.s 
specifies  .1  context  which  the  system  must  he  operating  under1’  .  It  ni.i>  .1K0  test  against  the  data  in  working 
memory.  and  may  test  against  the  contents  of  the  goal  tree. 

4.2.1.  Pattern  Matching 

The  tests  on  the  left-hand  side  are  accomplished  through  a  process  known  as  pattern  matching.  Hits  means 
that  each  test  is  a  pattern  la  parameterized  description  of  what  something  must  "look  like")  which  must  match 
against  some  data  item  in  working  memory  or  in  the  goal  tree'  . 

Since  patterns  arc  of  major  importance  when  writing  GRAPHS  productions,  they  will  he  described  first. 
Then,  a  few  sections  will  be  devoted  to  explaining  how  these  patterns  are  used  to  form  tests  on  the  left-hand 
side  of  a  production. 

4. 2. 1.1.  Constant  Patterns 

The  simplest  t>pe  of  pattern  is  a  single  constant.  Constants  specify  exactly  the  data  item  which  is  to  be 
matched.  Any  ordinary  atom  (that  is.  an  atom  which  is  not  a  x ariablc)  is  by  default  defined  to  be  a  constant. 
For  example, 

has-relatlonshlp 

is  a  legal  GRAPHS  pattern  which  only  matches  against  the  daw  item: 

has-relatlonship 

Patterns  can  be  constructed  by  forming  a  list  from  other  patterns.  For  example,  the  following  arc  also  legal 
GRAPES  patterns: 

(Is-a  LISP  programming-language) 

(LISP  has-functlons  named  (car  edr  cons)) 


the  left-hand  side  must  contain  a  specification  of  the  current-goal 
these  items  must  fit  the  given  description 
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4. 2. 1.2.  Variable  Patterns 

Patterns  would  mu  he  wi \  useful  if  they  cctilil  <<nl>  contain  constants.  1 1ns.  however.  is  not  the  case, 
i’.iltcrus  ,ne  permuted  to  contain  vai  i.iblcs.  \  v.u uble  (.ii.tii.il I . .  an  ordinal v.u  uble)  is  an  atom  which  beams 
with  the  eh.ir.ieter  = .  \  an. iMes  do  not  speed;.  exactly  how  the  uutelied  data  item  looks:  instead,  diey  enable 
the  user  to  describe  a  class  of  data  items  which  will  match  to  a  pattern.  Variables  can  match  to  any  legal 
symbolic  expression,  l-or  example,  the  following  is  a  legal  GRATIS  pattern: 

-something 

which  will  match  to  an>  of  the  following  data  items: 

some-cons  Cant 
(a  list) 

(a  more  (complex)  (( 1 1 st- structure) ) ) 

Variables  can  be  part  of  a  larger  pattern.  For  example,  the  pattern 

( has-rel atlon  -argumentl  “relation  «argument2) 

w  ill  match  to  any  of  the  follow  mg  data  items: 

(has-relatlon  llstl  first  (llstl  11st2  11st3)) 

(has-relatlon  list!  same-as  llstl) 

(has-relatlon  green  (some  physical-property)  (grass  crayons  etc)). 

4. 2. 1.3.  Variable  Bindings 

Variables  have  a  very  important  property.  During  the  match  process  they  become  bound  to  the  data  item  or 
portion  of  a  data  item  which  they  match  to.  The  value  which  a  variable  becomes  bound  to  is  called  its  binding. 
For  example,  when  the  pattern 

(hes-rel atlon  -argumentl  “relation  “argument2) 

is  matched  against  the  data  item 

(has-relatlon  green  (some  physical-property)  (grass  crayons  ate)) 

the  variable  =  argument!  becomes  bound  to  the  atom  green,  the  variable  =  relation  becomes  bound  to  the  list 
(some  physical- property),  and  the  variable  =  argument?  becomes  bound  to  (grass  crayons  etc). 

When  the  same  variable  occurs  more  than  once  m  the  same  pattern  (or.  as  we  shall  see  later,  in  the  same 
production),  it  must  bind  to  die  same  data  item  each  time.  Thus,  the  pattern 

(has-relatlon  “argi  same-as  >argl) 

will  match  to  die  data  item 

(has-relatlon  llstl  same-as  llstl) 
but  not  to  any  of  these  data  items: 
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(has-relatlon  llstl  same-as  11st2) 
(has-relatlon  llstl  same-as  LIST1) 
(has-relatlon  llstl  same-as  (llstl)) 


4.2.1 .4.  String  Variables 

Patterns  nu\  also  contain  another  type  of  variable,  called  a  urnn;  windin'  (or  a  st  ^mcui  wimble).  A  string 
variable  is  an  atom  which  begins  with  the  character  String  variables  are  similar  to  regular  variables, 
except  that  they  bind  to  a  series  of  (zero  or  more)  expressions  within  a  data  item.  String  variables  always  bind 
to  a  list  (or  nil),  but  this  list  appears  spiiccJ  within  die  data  item  (that  is.  each  element  in  the  binding  of  a 
string  variable  is  at  the  same  depth  sir'  list  structure  as  the  surrounding  terms  in  the  data  item). 


For  example,  when  the  pattern 

(has-relatlon  argl  first  (argl  Sremalnlng-ltems) ) 

is  matched  against  the  data  item 

(has-relatlon  argl  first  (argl  arg2  arg3)) 

the  string  variable  "Srcmaining-iicms"  becomes  bound  to  die  list  ''(arg2  arg3)'\ 

String  variables  arc  meant  to  be  used  to  matched  pieces  of  a  list.  They  will  only  match  zero  items  when  die 
list  is  non-empty.  Matching  against  nil  can  be  done  with  calls  to  I  ISP  (explained  in  section  4.1.5). 

Note  that  sometimes  string  variables  may  introduce  ambiguity  into  a  pattern.  However,  diis  is  often 
desirable.  For  example,  if  the  pattern 

(Sllstl  "term  J11st2) 

is  matched  against  die  data  item 

(argl  srg2  srg3), 

then  there  arc  three  possible  sets  of  variable  bindings  which  result: 

1.  Slistl  bound-to  nil 

=  tcrm  bound-to  argl 
Slist2  bound-to  (arg2  arg3) 

2.  Slistl  bound-to  (argl) 

=  tcrm  bound-to  arg2 
Slist2  bound-to  (arg3) 

3.  Slistl  bound-to  (argl  arg2) 

=  tcrm  bound-to  arg3 
Slist2  bound-to  nil 


i 
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4. 2. 1.5.  Patterns  Returned  from  Functions 

There  is  one  rein. lining  type  of  entity  which  m.iy  occur  within  a  GRAM  S  pattern.  I  his  is  an  external 
function  call.  External  function  calls  will  he  described  in  detail  in  section  fixe.  Ilowexer.  as  an  example  if  the 
top-goal  has  no  subgoals,  then  the  pattern 

(Is-a  (‘subgoals  top-goal)  empty-list) 
will  match  to  the  data  item 

(1s-a  nil  empty-list) 


4.2.2.  Production  Parameters 

Production  parameters  specify  the  context  wl  ich  the  system  is  operating  under.  I-'.ach  production  fires  in 
the  context  of  the  current  goal.  Production  parameters  are  uttributeAalue  pairs,  entirely  analogous  to  those  of 
the  goals  in  the  goal  tree,  except  dial  the  xalucs  can  be  GRAPHS  patterns  (as  described  in  section  4.1.1).  Hach 
production  must  have  an  action:  parameter,  whose  value  is  a  non-nil  atom.  All  other  parameters  arc  optional. 
For  a  parameter  match  to  be  successful,  the  current  goal  must  have  that  parameter's  attribute  and  the 
corresponding  value  must  match  the  specified  pattern.  However,  the  current  goal  can  have  other  attributes 
not  specified  in  the  parameter  list,  and  the  parameter  patterns  will  still  match.  For  example,  if 
(P  P-1 

action:  make 
object:  =thing 
tests : 

(is-a  =thing  good) 

==> 

(make  =thing)  ) 

was  a  production  in  production  memory,  and 

(goal -4 

(action:  make 
object:  cake 
color:  brown)) 

was  the  current  goal,  then  p-1  would  parameter  match  to  goal-4.  After  parameter  matching  would  come 
working  memory  matching  and  goal  matching.  If  all  of  these  tests  passed,  then  the  production  would  be 
placed  in  the  conflict  seft  , 
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see  section  five 


14 


4.2.3.  Working  Memory  Tests 

All  GRAPES  working  mcmnr\  lests  arc  in  the  tests:  section  of  the  production.  Phis  section  is  an  optional 
part  ot'a  GR  API'S  production,  ill  ten  the  goal  context  alone  is  .1  sulTicient  precondition  for  the  production  to 
lire.  GRAPES  working  memory  tests  are  simple  patterns,  as  described  in  section  4.1.1.  These  patterns  are 
matched  against  working  memory.  I  he  only  restriction  on  working  memory  tests  is  that  they  may  not  begin 
with  die  constants  goo/,  subgoal.  or  supergoal.  and  Utcy  may  not  make  references  to  external  functions  which 
arc  not  defined  (however,  the  user  can  always  define  his  own  external  functions). 

These  are  examples  of  legal  working  memory  tests: 

(has-ralatlon  -var  -relation  (Jargset)) 

(has-color  (’pattern  -flog  (’length  Jcolorset))  -color) 


These  are  examples  of  illegal  working  memory  tests: 

(goal  pick-up  -block)  ;  Begins  with  a  goal-word 

(has-relatlon  (’make-pattern  -this))  ;  Undefined  functlon’make-pattern 

4.2.4.  Goal  Tests 

lake  working  memory  tests.  GRAPHS  goal  tests  arc  in  die  rests:  section  of  the  production.  GRAPES 
maintains  the  goal  tree  internally .  Many  features  have  been  added  to  make  goal  matching  as  flexible  as 
possible.  A  goal  specification  is  a  pattern  of  the  form: 

(  <type>  [  <of-goa)>  [  <name>  ]] 

<parameters>  [  <goall>  [  <goal2>  ...  ]]  ) 

<type>  Either  goal,  subgoal,  or  supergoal. 

<of-goal>  A  goal  name  (not  valid  for  type  goal),  which  specifies  that  die  search  for  subgoal  or 

supergoal  begins  here. 

<name>  The  name  of  the  goal  with  the  given  parameters. 

<paramctcrs>  The  list  of  goal  parameters.  For  example: 

(action:  writs 
function:  -name) 

<goal  n>  if  given,  each  is  a  nested  goal  specification. 

Specifying  a  type  goal  in  the  goal  test  means  that  any  active  goal  may  try  to  match  to  diis  specification 
Specifying  the  type  supergoal  means  dint  any  active  goal  which  is  higher  in  the  goal  tree  than  <of-goal>  may 
be  considered  for  matching.  Specifying  the  type  subgoal  means  that  any  active  goal  which  is  lower  in  the  goal 


tree  tlt.iii  <ot-gu.il>  m;iy  be  considered  lor  matching. 

4.2.4. 1 .  Nested  Goal  Tests 

The  goal  name  <of-goal>  defaults  to  the  current  goal  in  an  outer  les  cl  goal  test.  If  a  goal  test  is  being  nested, 
die  following  rules  sped  Iky  die  the  default  value  of  <of-goal>: 

1.  Type  goal  -  an  immediate  subgoal  of  the  enclosing  goal  specification. 

2.  I'ypc  subgoal  or  supergoal  -  die  goal  matched  by  die  enclosing  goal  specification. 

Note  that  if  any  nested  goal  test  fails,  then  the  entire  test  fails. 

4. 2. 4. 2.  Goal  Test  Parameters 

The  parameters  arc  analogous  to  those  described  in  section  3.  They  consist  of  attributc/valuc  pairs.  Fateh 
attribute  must  be  an  atom,  but  the  values  may  be  arbitrary  GRAPHS  expressions  (however,  they  must 
evaluate  to  a  non-nil  atom  or  list).  Parameters  arc  optional. 


If  the  goal  tree  were  as  follows: 


top-goal  (action:  recognize  object:  ball) 
(action:  decide)  gaal-1  goal-2  (action:  declda) 


goal-3 
(action:  move 
object:  ball 
place:  left) 


goal-4  goal-5 

(action:  go  (action:  recognize 
place:  house)  object:  room 
area:  house) 


and  the  current  goal  was  goal-2,  then  the  following  would  be  legal  goal  tests: 

TESTS:  MATCHES: 


(goal  «goal 

(action:  recognize 
object:  "object)) 

(super  goal 
(action:  recognize 
object:  ("bind  -name  ball))) 

(subgoal  top-goal  "name 
(action:  decide) 

(goal 

(action:  move 
object:  JobJects))  ) 


(goal 

(action:  decide 
reason:  "reason)) 


top-goal 

goal-6 


top-goal 


goal-1 

with  subgoal  goal-3 


no  matches 
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I  hoc  following  would  bo  illegal  tests  against  the  goal  tree: 


urn- 


REASON  for  ILLEGALITY: 


(top-goal 

(action:  rocogntzs 
object:  ball)) 

(supergoal  -goal  -goal2 
(action:  move) 
(object:  ball) 
(place:  -place)) 

(goal  -of  -name 
(action:  go 

place:  -placet)) 


top-goal  not  a  legal  type 


Illegal  format 


<of-goal>  should  not  be 
present  In  type 


4.2.5.  Left-Hand  Side  Function  Calls 

There  arc  a  variety  of  external  function  calls  available  to  the  GRAPHS  user.  They  can  he  arbitrarily  nested 

in  the  patterns  (as  above),  or  may  be  used  on  the  outer  level  as  in: 

("success  -goal) 

which  would  return  i  or  nil  depending  on  whether  the  goal  which  bound  to  =goal  was  successful  at  the  time 
this  condition  was  tested,  or  whether  the  goal  was  not  successful.  If  i  is  returned,  die  other  conditions  of  the 
production  continue  through  die  matching  process.  If  nil  is  returned,  the  production  fails. 

Function  calls  can  be  built-in  GRAPES  'functions  like  'pattern  and  'current-goal,  or  they  can  be  user 
defined  'functions  loaded  in  as  a  special  module9.  In  addition,  regular  LISP  functions  can  be  used  on  the 
left-hand  side.  If  an  atom  begins  with  "*"  and  does  not  have  a  function  definition.  GRAPHS  calls  the 
function  without  the  This  can  be  used  quite  effectively  when  matching.  For  instance:  ('not  ('equal 
=  rcsultl  =rcsult2))  will  match  only  when  =rcsultland  =  result2bind  to  different  values. 

There  arc  two  types  of  outer-level  function  calls:  those  that  return  a  boolean  value,  and  those  that  return  a 
pattern.  If  a  function  call  returns  a  pattern,  it  is  matched  against  working  memory.  If  it  returns  a  boolean 
variable,  the  production  will  fail  when  the  boolean  value  is  nil.  Function  calls  arc  described  in  more  detail  in 
section  five. 

4.2.6.  Negative  Tests 

If  a  left-hand  side  pattern  is  preceded  by  a  symbol,  then  that  pattern  is  taken  to  be  a  negative  test.  If  the 
pattern  is  a  working  memory  tests,  this  means  that  the  given  production  will  match  only  if  no  elements  in 
working  memory  match  to  the  pattern.  If  the  pattern  is  a  goal  test,  then  the  given  production  will  match  only 
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see  a  description  of  the  I  ISP  module  in  appendix  seven 
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inhere  is  no  goal  in  the  goaf-tree  (or  no  s ttpayonl  or  siihgo.il.  depending  on  i he  go  if  t;.pe>  which  matches  the 
xpecific.ition.  It' the  pattern  is  an  ouicr-leu'l  function  call  which  doesn't  return  a  pattern,  then  the  pioduetton 
will  match  only  if  the  call  returns  ml. 

As  an  example: 

(P  P-2 

action :  get- tense 
word:  =word 
tests : 

-  ( is-a  =word  plural ) 

=  => 

(is-a  =word  s i ngu 1 ar ) ) 

which  says  that  if  there  is  nothing  in  memory  which  suss  that  the  word  is  plural,  then  it  is  singular. 


4.2.7.  Partial  Matching 

If  a  left-hand  side  pattern  is  preceded  by  a  "?"  symbol,  then  that  pattern  is  matched  as  a  positive  test.  If  the 
matching  succeeds,  the  variables  arc  treated  like  they  arc  in  a  positive  test.  If  the  pattern  does  not  match,  the 
pattern  is  considered  to  be  a  negative  test,  and  those  variables  only  mentioned  in  the  pattern  are  not  given 
bindings.  This  facility  can  be  used  to  produce  partial  matching  and  ordering  of  productions  based  on  their 
degree  of  match.  In  addition,  the  partial  match  test  can  be  used  in  conjunction  with  right-hand  side  patterns 
using  the  same  variable.  For  instance,  if  use-name  were  a  production: 

(p  use -name 

action:  get-name 
tests : 

( name-1 i st  Snames ) 

?  (has-name  =object  =name) 

(object-list  Sobjl  =object  $obj2) 

*=> 

(•remove  1) 

(name-list  Snames  =name)  ) 


it  might  add  the  name  of  an  object  to  a  name-list.  If  the  object  already  had  a  name,  it  would  use  that  name 
and  if  the  object  did  not  have  a  name,  a  new  name  would  be  made.  Sec  section  below  for  information  on  how 
a  new  name  is  made. 


4.3.  The  Right-Hand  Side 

The  action  side  is  an  ordered  list  of  zero  or  more  GRAPES  expressions.  Once  conflict  resolution  has 
picked  one  instantiation  of  a  particular  production  and  all  line  variables  on  die  left-hand  side  have  bindings, 
that  production's  right-hand  side  is  evaluated  from  top  to  bottom.  The  right  hand  side  can  put  elements  into 
working  memory,  put  goals  into  the  goal  tree,  or  execute  LISP  functions.  These  are  each  described  in  the  next 
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throe  sections. 


4.3.1 .  Additions  to  Working  Memory 

If  a  CiRAI’ES  pattern  iv  found  on  the  right-side  side  of  a  production,  and  its  first  element  is  not  a  goal-nvrj 
(supergoal,  subgoal.  goal)  or  a  function  call,  then  it  is  evaluated  and  stored  in  working  memory.  All  variables 
in  the  pattern  which  had  bindings  on  the  left-hand  side,  are  evaluated  according  to  those  bindings,  if  a 
variable  was  not  bound  on  the  left-hand  side,  then  a  binding  is  made  for  die  variable,  and  it  is  bound  using 
the  '“bind  function10  .  1  he  new  value  looks  like  the  variable  but  is  guaranteed  to  be  unique.  For  instance,  if 
the  variable  =var  was  found  on  the  right-hand  side  without  a  binding,  then  a  value  which  looks  something 
like  (b  varl  would  be  bound  to  that  variable. 


4.3.2.  Additions  to  Goal  Memory 

All  right-hand  side  patterns  beginning  with  a  goal-word  are  added  to  the  appropriate  place  in  the  goal  tree. 

The  goal  patterns  look  very  similar  to  the  patterns  which  match  to  them.  Haeh  goal  is  of  the  form: 

(  <type>  [  <of-goal>  [  <name>  ]] 

<parameters>  [  <goa11>  [  <goal2>  ...  ]]  ) 

<typc>  Either  goal,  subgoal,  or  supergoal. 


<of-goal> 

<namc> 

<namc> 


A  goal  name  which  will  have  as  a  new  supcrgoal  or  subgoal. 

The  default  value  is  the  current  goal  or  the  goal  specified  above,  if  it  is  a  nested  goal 
specification. 

The  name  of  the  goal  with  the  given  parameters. 


<paramctcrs>  The  list  of  goal  parameters.  For  example: 

(action:  wrlta 
function:  •name) 


<goal  n> 


if  given,  each  is  a  nested  goal  specification. 


-  However,  the  goal  words  arc  interpreted  differently.  If  the  goal  <typc>  is  goal  or  subgoal,  the  new  goal  is  set 
as  an  immediate  subgoal  to  <of-goal>  or  or  an  immediate  subgoal  to  the  current  goal  if  <of-goa!>  is  not 
specified.  If  goal  specifications  arc  being  nested.  <of-goal>  defaults  to  die  goal  above  the  goal  specification 
being  defined.  If  the  goal  type  is  supergoal,  the  goal  is  set  as  a  new  supcrgoal  to  <of-goal>.  Examples  of 
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see  section  6 
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inserting  goals  .no  given  below. 


Inserting  a  suOapal 

top-goal  top-goal 

goal-1  < —  of-goal  — >  goal-1 

goal-2  goal-3  goal-2  goal-3  goal-4  < —  new  goal 

Before  After 

Inserting  a  suoerooal 
top-goal  top-goal 

goal-1  < —  of  goal  goal-4  < —  new  goal 

goal-2  goal-3  goal-1  < —  of-goal 

goal-2  goal-3 

Before  After 

Wiili  any  goal,  if  the  goal  <namc>  already  exists,  an  or  node  is  pushed  onto  the  supergoal  of  <namc>.  That 
is.  the  old  goal  and  its  subgoals  are  replaced  by  the  new  one.  The  or  node  will  be  a  new  goal  which  has  as  its 
subgoals  all  of  the  old  subgoals  (thus  preserving  the  old  state  of  the  goal  tree  through  this  new  node).  This 
enables  the  system  to  remember  its  previous  moves  and  act  accordingly.  Putting  goals  into  various  places  in 
the  goal  tree  can  sometimes  alter  die  status  of  already  successful  goals.  For  instance. when  inserting  a  subgoal 
(sec  above),  the  of-goal  would  become  an  active  goal  even  if  it  was  prev  iously  successful.  The  new  goal  adds 
additional  contraints  to  the  satisfaction  of  the  of-goal.  All  subgoals  of  a  given  goal  must  be  successful  for  the 
goal  to  be  successful.  For  more  information  on  the  goal  structure  sec  section  3. 

4.3.3.  Right-Hand  Side  Function  Calls 

If  a  GRAPHS  pattern  has  a  ‘function  as  its  first  element,  then  that  function  is  evaluated  according  to  the 
bindings  of  the  current  instantiation.  If  that  function  yields  a  working  memory  element,  then  that  element  is 
stored  in  working  memory.  The  function  may  also  return  a  boolean  value.  If  the  value  is  non-nil.  the  rest  of 
the  right-hand  side  is  evaluated.  If  the  value  is  nil.  die  rest  of  the  right-hand  side  is  ignored11  .  Right-hand 


11 


this  docs  not  mean  the  production  won't  match,  since  matching  has  already  taken  place 


:o 

sulc  functions.  like  left-h.md  side  functions.  can  he  defined  in  1  1  SI'  or  user  defined1 


*^sce  section  4.1.5 
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5.  The  Recognize-Act  Cycle 

k\  hen  running.  the  system  goes  through  a  senes  of  rco/gnizi-uci  cycles.  In  each  e>tle  the  system  goes 
through  the  following  steps: 

1.  GRAPHS  looks  through  the  goal  tree  and  finds  a  goal  which  it  wants  to  solve.  1  his  goal  becomes 
the  locus  of  attention  during  this  cycle,  and  is  called  die  current- &ual. 

2.  GRAPHS  looks  through  its  production  set  and.  based  on  die  contents  of  working  memory,  the 
current  goal,  and  the  remaining  goals  in  the  goal  tree,  chooses  a  subset  of  the  productions  winch  it 
drinks  is  relevant  to  sob  ing  the  current-goal.  I  his  subset  is  called  die  conflict  set. 

3.  A  process  known  as  conflict  resolution  is  applied,  whose  purpose  is  to  single  out  one  production 
from  the  conflict  set  which  will  be  used  to  try  and  solve  the  current-goal.  If  dierc  is  no  such 
resulting  production,  then  GRAPHS  decides  that  it  cannot  solve  die  current-goal,  and  we  go  back 
to  step  1.  Otherwise,  die  resulting  production  is  called  the  current-production. 

4.  GR APRS  Jtres  the  current-production.  If  we  take  the  view  that  each  production  is  a  miniature 
program,  dicn  this  means  diat  GRAPHS  runs  the  current  program.  When  this  happens,  many 
changes  in  the  program  environment  can  occur.  Data  can  be  added  to  or  deleted  from  working 
memory,  and  new  goals  may  be  inserted  into  the  goal  tree. 

5.  GRAPES  goes  back  to  step  1.  beginning  a  new  cycle  in  the  context  of  a  new  program 
environment. 

Each  of  diese  steps  is  treated  in  detail  in  die  next  few  sections. 

5.1 .  Finding  the  Current  Goal 

The  current  goal  is  always  the  deepest  and  left-most  node  in  the  goal  tree  which  has  not  yet  reached  success 
status.  The  current  goal  reaches  success  status  when  : 

1.  All  of  the  current  goal’s  subgoals  have  reached  success  status,  or 

2.  A  production  explicitly  states  that  the  goal  is  successful. 

The  current  goal  is  matched  against  the  patterns  in  the  production’s  parameter  list  using  the  matching 
algorithm.  The  current  goal  must  have  an  action  which  is  an  atom  identical  to  that  of  the  production  action 
attribute.  In  addition,  all  of  the  attributes  specified  in  the  production  must  be  present  in  tine  goal,  also. 


5.2.  Matching  -  Determining  the  Conflict  Set 

I  In:  GR  \1‘I  S  mulching  algorithm  is  buMc.illv  .i  u  tvpe.  When  being  compiled.  each  .ell  Ii.hkI  vide 

pane  rn  makes  a  function  doiimiion.  I  hese  function  dvfliiitioiis  are  used  u>  mutch  igumM  work  my  memorv 
and  the  goal  live.  I  he  mukh  network  is  ;>r,  . •ni/n.'cd  in  die  sense  dial  mast  patterns  are  mu  uctu.dlv  maielied 

during  the  matching  part  »>i'  the  cycle.  I  he  m.itclimg  is  dune  before-hand,  when  working  meinori  ana  goal 
memor>  are  being  defined.  1  he  matches  for  each  pattern  are  updated  each  tune  an  item  is  put  into  working 
memorv  or  goal  memory.  I  liis  item/.Vnv  through  the  match  network  creating  variable  bindings  as  it  goes. 

At  die  match  part  of  the  production  cycle.  the  matches  of  each  pattern  are  analyzed  to  sec  if  they  are 
consistent  with  goal  memory  and  woikmg  memory.  Ml  productions  patterns  arc  examined  at  this  lime,  dnis 
the  productions  are  being  tested  in  parallel.  Some  GRAPHS  patterns  require  dynamic  matching''  .  I  hat  is. 
their  possible  matches  can't  be  determined  ahead  of  time.  All  1  .ISP  function  calls  and  some  goal  tests  have  to 
be  matched  dynamically. 

When  all  matching  is  done,  a  given  production  may  have  matched  in  several  wavs  each  of  these  possible 
production  possibilities  is  an  instantiation.  The  process  of  deciding  among  these  instantiations  is  called 
conflict  resolution. 

5.3.  Conflict  Resolution 

GRAPHS  uses  five  basic  rules  to  decide  among  competing  instantiations.  Goal  memorv  makes  die  first  rule 
possible.  The  second  rule  is  a  heuristic  used  to  make  die  system  more  efficient.  The  third  rule  comes  from  the 
working  memory  structure.  The  flexibility  of  GRAPHS  patterns  makes  the  fourth  rule  possible.  The  final  rule 
is  used  only  as  a  last  resort. 

These  rules  for  ordering  instantiations  arc  done  in  sequence.  Those  that  follow  the  action  test  arc  passed  on 
to  the  refraction  test.  Those  that  pass  that  test  arc  sent  on  to  the  next  test,  and  so  on.  In  the  end.  one 
production  instantiation  remains  (thus  GRAPHS  has  no  parallelism  in  its  firing  mechanism).  The  rules  arc 
listed  in  order  below. 

5.3.1.  Action  Specification 

Each  production  must  have  an  action.  Only  instantiations  of  productions  with  the  same  action  as  the 
current  goal  can  apply.  This  restriction  can  be  used  by  a  GRAPHS  programmer  to  isolate  productions  into 
subroutines,  groups  of  productions  which  apply  to  a  particular  task,  if  all  actions  arc  equal.  GRAPHS  will  look 
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sec  section  4 
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at  .ill  tho  productions.  I  he  possibility  i>r  '.ubiiuiuncs  cun  lv  taken  to  .m  sxticmc.  however.  A  different  .wtiun 
for  each  pio.kicuon  would  make  the  ci'nilicl  set  !  every  nine.  1  his  would  .m  uninteresting  production  system 
tor  most  .ippiicutions. 

5.3.2.  Refraction 

bach  production,  once  used  at  a  particular  goal,  cannot  lire  with  die  same  same  bindings  at  die  same  goal, 
lilts  is  to  prevent  the  system  from  getting  into  one  production  loops  (though  longer  loop  cycles  are  possible). 


5.3.3.  Recency 

Hach  working  memory  element  and  goal  element  has  a  nun’  Art;  associated  with  it.  which  denotes  when  it 
was  put  into  working  memory,  those  instantiations  which  matched  to  die  most  recent  working  memory 
elements  arc  preferred.  Although  GR  APHS  contains,  at  tins  time,  no  decay  of  working  memory  elements,  tills 
instantiation  ordering  strategy  approximates  decay  to  some  extent,  [-dements  most  recently  entered  into 
memory  probably  have  more  relevance  to  the  problem  at  hand. 

5.3.4.  Specificity 

Fach  GRAPHS  pattern  has  a  specificity  associated  with  it.  The  production  goal  parameters  and  die  tests- 
against  working  and  goal  memory  arc  all  considered  for  resolution  on  a  basis  of  specificity.  A  few  simple  rules 
arc  followed  when  deciding  die  specificity: 

1.  A  list  is  more  specific  dtan  a  constant. 

2.  A  constant  is  more  specific  than  a  variable. 

3.  A  regular  ( = )  variable  is  more  specific  than  a  segment  variable. 

Specificity  allows  the  more  specific  productions  to  apply  when  in  competition  with  more  general 
productior Since  productions  arc  never  removed  from  production  memory,  this  can  be  a  very  important 
ordering  strategy14  . 


14 


this  becomes  even  more  important  when  a  system  includes  learning  mechanisms,  like  (he  next  version  of  GRAPHS 


24 


5.3.5.  Randomness 

If.  jftci  applying  all  the  ordering  rules  to  the  producin' n  msi.uui.iiioiis.  a  list  of  possible  in\,..uiu.il!uns  'till 
remains.  ihc  s’. stem  pieksoiie  at  random. 


5.4.  Firing  a  Production  Instantiation 

W  hen  one  instantiation  of  a  particular  production  is  chosen,  the  r<on yi/se  part  of  the  c;.de  is  over.  and  the 
system  performs  actions.  \  arious  actions  can  be  performed: 

1.  \dditions  to  working  memory 

2.  \dditions  to  goal  memory  (vubgoals  or  inserted  goals) 

3.  Removal  from  working  memory 

4.  Calls  to  pre-defined  functions  (input  and  output  fall  under  this  category) 

5.  Calls  to  1  ISP  (user  defined  functions  or  1  ISP  primitive  functions) 

Each  of  these  jets  is  described  in  more  detail  in  section  4  on  production  light  hand  side  actions.  It  must  be 
stressed  that  GRAPHS  productions'  right  hand  sides  arc  not  executed  in  parallel.  The  sequences  of  actions  is  a 
linear  description  of  what  the  system  should  do. 

5.5.  Continued  Processing 

The  recogni/e-aot  cycle  is  performed  again  and  again  unul  the  system  is  explicitly  halted,  or  ur:  .  • 
top-goal's  status  is  determined.  At  each  cycle  a  new  environment  is  formed  which  the  system  must  adjust  .o. 
The  essential  parallel  nature  of  production  systems  is  partially  avoided  in  GRAPES,  where  goal  structure 
plays  a  key  role.  Proper  use  of  the  GRAPES  control  structure  can  make  programming  in  a  Production  system 
language  much  easier. 
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6.  User  Functions 

( i Is  M'l  S  !us  .1  .  ■!'  ps  e-dcfiuo.i  bastions  Inch  ud  ills'  usci  m  Anting  pi od  net  ion-.  I  lie  names  of  c.ich 

'i  those  in... ;  vns  ice m  a  iili  .i  .h.u.ivic  Ml  .hems  Ah.J;  ,hc  '.he  fiist  element  of  a  W  and  have  a  "*"  as 
:lio  fust  . ii.ii. .sici  m  :hc:i'  ti  .me  me  considered  hi  be  .alls  i.t  exiein.il  I  ISI’  tuiisiiuiis.  \  M.nmur.  of  user 
functions  ;s  in  appendix  II. 

6.1 .  General  Functions 

I  liese  functions  are  general  purpose  functions  and  can  he  ased  either  on  die  left-hand  side  or  on  the 
right-hand  side  of  a  production.  Mso.  the.,  e.in  ‘v  nested  Aithm  working  memory  tests,  etc.:  die;,  do  not  need 
to  he  outer-lex  el  function  cails. 

‘hind 

form:  (“bind  =  var  value) 
arcs:  =xar:  A  xariahle  name. 

value:  A  lisp  expression,  possihh  containing  GltAPHS 
variable  names, 
sv  nopsis: 

Creates  variable  bindings.  If  the  given  variable  is 
unbound,  then  its  binding  is  set  to  the  given  value.  If  the 
variable  lias  already  been  bound  to  the  given  value,  then 
nothing  happens,  but  the  binding  operation  is  still  considered 
to  be  successful.  If  the  variable  has  alrcadv  be  :n  bound,  but 
to  a  different  value,  then  tiro  binding  is  unsuccessful, 
returns: 

The  specified  value,  if  the  binding  a  us  successful.  If  the 
binding  is  unsuccessful,  and  we  arc  on  die  right-hand  side  of 
a  production,  then  "nil"  is  returned.  An  unsuccessful  binding 
on  the  left-hand  side  of  a  production  causes  that  production 
instantiation  to  fail, 
side  effects: 

The  given  variable  becomes  bound  if  the  binding 
was  successful. 

'current-goal 
form:  (*currcnt-goal) 
a rgs:  none, 
synopsis: 

Gets  the  name  of  the  current  goal, 
returns: 

The  name  of  the  current  goal. 
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•length 

form:  I  ‘length  |.ugl  aigd  ..  |) 

arcs:  I  aeh  .ngti)  is  optional  .mil  may  he  ,m>  expression. 
s\  mipsis: 

Cie.ites  .1  list  of  unbound  -.unable  names.  1  lie  number  of 
i.irunles  in  the  list  is  tile  Mine  as  the  number  ol  arguments 
passed  to  the  funetion.  Hus  is  useful  :n  conjunction  with  tlie 
•pattern  and  ‘match  functions, 
returns: 

A  list  of  unbound  ‘.unable  names. 

As  an  example,  if  the  variable  "Surgset"  is  bound  to  the  list 
"(nrgl  ,ug2  argil",  then  the  call: 

( ‘length  Sargset) 
would  return  something  like 

t  =  voooi  =vuoo:  -V0003). 


•match 

form:  t 'match  pattern  expression) 

arcs:  pattern:  An  expression  containing  constants,  variables,  etc. 

expression;  Any  expression, 
svnopsis: 

I  ries  to  match  die  given  pattern  to  the  given  expression, 
returns: 

"t"  if  the  match  was  successful.  Otherwise,  returns  "nil", 
side  effects: 

If  the  match  was  successful,  then  all  variables  in  the 

given  pattern  which  were  previously  unbound  arc  now  given 

bindings. 


•new 

form:  (*ncw  =  symbol) 

args:  =  symbol:  A  variable  name. 

synopsis: 

Creates  new  symbols.  The  =  symbol  given  should  be  an  unbound 
variable  name, 
returns: 

A  new  atom  which  looks  like  the  given  symbol  name.  For 
example,  "(*ncw  =arg)"  might  return  "@argl". 
side  effects: 

The  given  variable  is  bound  to  the  new  symbol,  using 
the  ‘bind  function. 


'pattern 


form:  (“pattern  |argl  ,irg2  ...]) 

args:  l.icli  argil >  in  optional  and  mat  bo  am  expression, 
synopsis: 

Creates  a  pattern  from  the  list  of  its  arguments.  I  his  is 
usually  used  in  conjunction  ss  uh  the  “match  function, 
returns: 

A  pattern,  which  is  usually  used  to  do  a  'match.  Kor 
example,  if  "Sargset"  is  bound  to  the  list  "(argi  arg2)".  then 
die  call: 

(“pattern  (‘length  Sargset)  =  \ar(“lcngth  Sargset)) 
would  return  something  like 

(  =  \  0001  =  \  0002  =  var  =  Y0U03  =  V0004). 


“subgoals 

form:  (“subgoals  [  =  goal-name]) 

args:  =  goal-name  (optional):  The  name  of  a  goal  in  die  goal  tree, 
synopsis: 

Gets  the  list  of  subgoals  of  the  specified  =  goal-name.  If  no 
goal  name  is  given,  gets  the  list  of  subgoals  of  die  current 
goal, 
returns: 

A  list  of  subgoals,  or  "nil". 

“supergoal 

form:  (“supergoal  [  =  goal-name]) 

args:  =goal-name  (optional):  The  name  of  a  goal  in  the  goal  tree, 
synopsis: . 

Gets  the  name  of  the  supergoal  of  the  specified  =  goal-name.  If 
no  goal  name  is  given,  gets  the  supergoal  of  the  current  goal, 
returns: 

The  specified  supergoal,  or  "nil". 

6.2.  Left-Hand  Side  Functions 

These  functions  arc  usually  used  on  the  left-hand  side  of  a  production,  since  dicv  test  for  properties  or 
conditions  exiting  during  the  execution  of  a  GRAPES  program. 

“gmethod 

form:  (“gmethod  [goal  (varj|) 

args:  goal  (optional):  The  name  of  a  goal  in  die  goal  tree, 
var  (optional;  goal  must  be  specified  if  var  is  specified):  A 
variable  name, 
synopsis: 
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Gets  the  method  .ixsoa.ited  wiih  the  ii\cn  goal.  It  no  goal 
is  specified.  it  is  assumed  to  he  the  current  goal.  It  "var"  is 
gnen.  then  the  method  of  the  specified  goal  is  hound  to  ”\ar" 

(using  the  "hind  function), 
returns: 

I  he  method  associated  with  the  specified  goal,  or  "ml"  if 
there  is  no  associated  method. 

‘methodp 

form:  (‘methodp  [  =  goal|  =  method) 

args.  =goal  (optional):  1  he  name  of  a  goal  in  the  goal  tree. 

=  method:  \nv  expression  which  is  a  legal  method  for  a  goal, 
synopsis: 

Matches  against  the  method  of  a  goal.  If  no  =goa!  is  specified, 
then  it  is  assumed  to  be  the  current  goal, 
returns: 

"t"  if  the  method  associated  with  the  goen  goal  matches  the 
gnen  expression,  otherwise,  returns  "nil". 

‘success 

form:  (‘success  =  goal) 

args:  =goal:  The  name  of  a  goal  in  the  goal  tree, 
synopsis: 

Tests  for  success  status  of  a  goal, 
returns: 

"t"  if  the  the  named  goal  has  been  successful:  otherwise 
(if  the  goal  has  failed  or  is  still  currently  active)  returns 
"nil". 

6.3.  Right-Hand  Side  Functions 

These  arc  functions  which  arc  used  on  the  right-hand  side  of  a  production,  since  they  perform  actions 
which  alter  properties  of  the  GRAPHS  program  environment. 

‘input 

form:  (‘input  [argl  arg2  ...]) 

args:  Kach  arg  is  an  arbitrary  expression.  Sec  below. 

synopsis: 

Reads  data  from  the  terminal.  Kach  arg  is  treated  as 
they  arc  for  ‘output,  except  that  unbound  GRAPES  variables 
arc  given  values  which  must  be  input  by  the  user, 
returns: 

"t". 


‘mapgoal 

I'urm:  (‘m.ipgo.il  =  \.n  list  [  =  result]  goal-spec) 

.ties:  =\.ir:  A  variable  name. 

list:  \  list  ot  aitini.iiA  expressions. 

=  result  (optional):  A  '..muhlc  name, 
goal-spec:  \  goal  specifteaiion.  in  the  same  form  as  a  goal 
specification  would  ordinarily  appear  on  the  RHS  of 
a  production, 
synopsis: 

Inserts  a  list  of  goals  into  the  goal  tree.  "  =  xar"  is  bound 
successively  to  each  member  of  the  gixen  list.  One  goal 
is  created  (according  to  the  gixen  go.il  specification)  on  each 
iteration:  thus,  it  is  usual!)  desired  to  have  "  =  -nr"  appear 
somewhere  within  the  goal  specification.  If  =  result"  is 
specified,  then  the  list  of  the  names  of  the  goals  created 
is  hound  to  it  using  the  ‘bind  function, 
returns: 

"t". 

‘mapstorc 

form:  (‘mapstorc  list) 

args:  list:  A  list  of  expressions. 

synopsis: 

Each  expression  is  stored  in  working  memory.  Each  such  expression 
should  be  a  list:  any  which  arc  not  lists  are  ignored, 
returns: 

”t”. 

‘method 

form:  (‘method  [goal]  expression) 

args:  goal  (optional):  The  name  of  a  goal  in  the  goal  tree. 

expression:  An  arbitrary  expression, 
synopsis: 

Sets  the  method  of  the  given  goal  to  be  the  given  expression. 

If  no  goal  is  given,  it  is  assumed  to  be  the  current  goal, 
returns: 

•r. 

‘output 

form:  (‘output  [argl  arg2  ...]) 

args:  Each  arg  is  an  arbitrary  expression  which  is  treated 
as  specified  below, 
synopsis: 
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Kach  arg(i)  is  treated  according  to  the  following 
specifications: 

1.  If  the  arg  is  a  string,  it  is  printed. 

2.  If  the  arg  is  a  list,  then  every  element  in  the  list  is  "*ouiput"ed. 

3.  If  die  arg  is  an  integer,  then  die  next  arg  is  ”*ootput"cd  that  number  of  times. 

4.  If  the  arg  is  then  a  carriage  return  is  printed. 

5.  If  die  arg  is  "it",  dien  die  next  arg  is  an  expression  which  evaluates  to  an  integer,  and  a  tab  to  that 
cursor  position  is  performed. 

6.  If  the  arg  is  "(ft dien  the  next  arg  is  evaluated  and  its  result  is  printed. 

7.  If  the  arg  is  a  GRAPHS  variable,  then  it  is  evaluated  and  its  result  is  printed. 

8.  All  other  args  arc  just  printed. 

returns: 

"t". 

•pop 

form:  (*pop  [status]) 

args:  status  (optional):  Hither  "success"  or  "failure", 
synopsis: 

Controls  die  flow  of  the  program  through  the  goal  tree  by 
explicitly  setting  the  status  of  the  current  goal.  Goals 
can  be  declared  to  be  a  success  or  a  failure.  If  no  status  is 
specified,  it  is  assumed  to  be  "success", 
returns: 

"t". 

•redo 

form:  ("redo  goal) 

args:  goal:  The  name  of  a  goal  in  the  goal  tree, 
synopsis: 

Specifics  that  the  given  goal  is  to  be  redone.  This  is  done 
by  removing  the  previous  status  of  the  goal  and  declaring  it 
to  be  active, 
returns: 

"t". 
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‘remove 

liii'm:  (‘remove  n) 
nrgv  n:  \n  integer. 
s>  ih'psis: 

Removes  an  element  from  working  tuemoiy  I  he  "mil"  woikmg 
memori  clement  (.is  specified  on  the  left  lund  side  of  the 
production)  which  actually  in. itched  during  the  current 
production  tiring  is  the  one  which  is  removed  Negative 
working  memory  tests  and  tests  which  failed  do  not  count 
(since  tines  did  not  match), 
returns: 

"t". 

* replace 

form:  (‘replace  =  new  oldl.ist  oldF.lcmeni  new  I  dement) 
args:  =  new:  An  unbound  variable  to  hold  the  new  list 
oldl.ist;  A  list. 

oldHlemcnt:  An  expression  in  oldl  ist. 
newF.lement:  A  new  expression, 
synopsis: 

This  is  the  GRAPHS  substitute  function.  It  binds  =  new  to  list 
which  is  the  same  as  oldl  .ist  except  that  every  occu ranee  of 
oldHlemcnt  is  replaced  by  ncwHlcment.  This  replacement  is  done 
over  all  levels  of  the  list 

6.4.  About  Function  Calls  in  GRAPES 

Any  atom  which  is  in  the  function  position  of  a  list,  and  which  begins  w  ith  die  character  is  considered 
to  be  a  call  to  an  external  LISP  function.  This  function  call  may  be  one  of  those  which  have  been  pre-defined 
by  the  interpreter  (as  outlined  in  the  previous  three  sections),  or  they  may  be  user-defined  LISP  functions 
which  have  been  slurped  in  by  the  user.  Doth  types  are  treated  the  same  by  GRAPES. 


6.4.1 .  Calls  to  Common  LISP  Functions 

When  GRAPES  secs  a  function  name  of  the  form  "name.  it  looks  for  a  definition  of  the  function  called 
"name.  If  there  is  no  such  function  definition,  then  it  looks  for  the  function  called  name.  Thus,  the  user  can 
use  most  LISP  functions  (those  which  are  defined  in  Franz  LISP)  inside  productions  by  attaching  a  to  the 
beginning  of  the  function  name.  For  example,  the  following  is  a  legal  function  call  in  GRAPHS: 

(•not  (‘equal  *11*tl  (*edr  ■11st2))). 
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6.4.2.  Defining  Your  Own  Functions 

I  he  interpreter  assumes  that  all  external  functions  are  written  in  such  a  way  that  all  arguments  arc 
evaluated:  that  is.  they  must  be  defined  as  LimbJiis  or  U\\pr\,  or  maern v  which  expand  to  iiimhihis  or  lexprs. 
I h is  means  that  thev  can  be  fairly  general  function  definitions.  'I lies  can  be  called  from  within  productions 
or  from  within  other  function  definitions.  The  user  can  also  use  any  of  die  pro-defined  GRAPHS  functions 
from  within  his  own  function  definitions. 

Writing  sour  own  user  functions  to  be  used  by  GRAPHS  is  easy:  they  are  simply  written  as  if  they  were 
going  to  be  used  by  any  LISP  program.  Don't  worry  about  passing  GRAPHS  variables  to  I  ISP  functions;  die 
GRAPHS  interpreter  docs  some  pre-processing  before  functions  arc  called  so  that  this  will  work.  For 

example,  the  function  call 

(•not  ("equal  «11stl  («cdr  *11st2))) 

will  be  pre-processed  so  that,  at  the  time  die  call  is  actually  made,  it  will  look  something  like: 

(not  (equal  ’(a  6  c  d))  (edr  * ( b  c  d)))). 

One  convention  used  in  pre-processing  is  that  all  GRAPHS  variables  which  are  bound  at  die  time  the 
function  is  called  arc  replaced  by  their  bindings  during  pre-processing.  Unbound  GRAPHS  variables, 
however,  arc  not  replaced  by  anything15  .  This  allows  a  variable  name  to  be  passed  to  a  user  function.  Then,  a 
(*bind  =var  value)  may  be  used  from  within  the  user  function  in  order  to  create  a  new  variable  binding. 

A  few  final  words  of  caution  arc  in  order  here.  First,  be  careful  with  functions  that  do  not  evaluate  their 
arguments  (like  nlambdas)  and  with  functions  that  evaluate  their  arguments  in  special  ways.  For  example,  it  is 

a  bad  idea  to  use  the  following  type  of  function  call  from  within  a  GRAPES  producuon: 

(•or  (*eq  «Hstl  •11st2) 

(•setq  "llstl  »som»-valu«)). 

In  general,  setqs  may  give  problems,  since  assigning  a  variable  a  L.ISP  value  docs  not  affect  the  value  which 
GRAPES  knows  about.  To  get  around  this,  use  the  *bind  function.  Finally,  be  careful  not  to  use  functions  in 
the  wrong  places.  For  example,  using  a  *mapstore  on  die  left-hand  side  of  a  production  will  not  necessarily 
cause  an  error,  but  will  have  some  very  strange  side  effects. 


15 


no  (‘new  =  symbol)  is  generated 
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7.  Using  the  Interpreter 

the  GRAPHS  interpreter  is  similar  to  rile  I  ISP  interpreter  ih.u  ii  is  embedded  within.  1  he  GRAPHS 
interpreter  allows  only  commands  which  are  defined  at  the  top  level'*'  .  Calls  to  functions  not  defined  in 
OKAPI  S  result  in  an  error.  It'  the  user  would  like  to  execute  I  ISP  commands  in  addition  to  GRAPHS 
commands,  he  must  type  tQL  II-'  1 !!)  or  QL  II- 1 !!  to  the  GRAPHS  monitor1  .  I  his  will  make  almost  all  l-ran/ 
I  asp  commands  available  (though  the  interaction  is  still  through  the  GRAPHS  interpreter).  QLIKT  inode  is 
used  to  load  in  I  ISP  files  for  auxiliary  systems  not  defined  as  modes18 . 


GRAPH'S  commands  which  take  no  arguments  can  simply  be  typed  as  an  atom,  f  or  instance: 


can  be  typed  as: 


(ptrace) 


ptrace 

with  the  same  effects.  This  feature  ts  also  available  in  QLIKT  mode.  However,  only  GRAPHS  functions  can 
be  typed  this  way. 


First  a  number  of  commands  useful  for  defining  a  production  environment  will  be  described,  then  a 
function  for  actually  starting  the  system  is  given.  Mechanisms  for  stopping  the  system  and  exiting  GRAPHS 
arc  looked  at  next,  followed  by  a  description  of  commands  to  reset  initial  conditions.  Finally  a  group  of  useful 
pretty-printing  functions  arc  described,  which  make  the  GRAPHS  productions,  goals,  and  working  memory 
accessible  to  the  user. 


7.1 .  Defining  the  System 

These  functions  help  to  set  up  a  GRAPES  programming  environment. 

slurp 

form:  (slurp  [file  name]  [file  name] ... ) 

arguments:  Each  file  contains  GRAPES  productions  or  system  commands 
synopsis: 

The  slurp  command  will  define  the  production  set  found  in  each  file. 
The  default  file  extension  is  "-grp",  so  dial  (slurp  junk)  will 
define  productions  found  in  the  file  "junk.grp".  If  no  file  name 


^these  arc  listed  in  appendix  1 

^This  may  be  the  default,  depending  on  what  version  you  arc  using 
18 

See  mode  command,  section  7.1 


is  gi\cn  or  the  tile  gi\ en  cannot  he  opened.  slurp  w ill  prompt  for 
another  tile  name,  lire  tile  mat  eontam  calls  to  other  s>stem 
commands  as  well.  It  is  often  useful  to  eontam  calls  to  "setgoal"  and 
"setwm"  within  a  ".grp"  tile,  so  that  they  will  he  defined 
automatically  when  the  tile  is  slurped  in. 
returns: 

"Production  Environment  Defined." 


{} 

form:  {  <comment>  f 

synopsis.  1  he  G RAPPS  comment  characters.  All  characters  between  the  curl 
brackets  will  not  he  read  by  the  interpreter, 
returns:  nothing 

setgoal 

form:  (setgoal  '(action:  <aetion> 

<other  parameters)) ) 
argument:  Must  be  a  legal  goal.19 

For  example,  a  legal  call  is: 

(setgoal  (action:  write 
argl:  arg-list 
result:  result-list)) 

synopsis: 

The  setgoal  command  sets  the  value  of  the  "top-goal".  The  top-goal 
is  the  default  goal  used  to  start  the  system, 
returns: 

A  message  concerning  die  success  or  failure  of  the  call. 


setwm 

form:  (setwm  '(  <!istl>  <list2>  <list3> ...) ) 
arguments:  Each  argument  is  a  list  representing 
one  working  memory  element/0 

synopsis: 

Setw  m  sets  the  contents  of  working  memory,  erasing  any  elements 
currently  there.  Setwm  expects  a  list  of  lists.  Each  list  is  stored 
ns  a  single  element  in  working  memory.  If  setwm  is  given  an  atom  to 
store,  it  simply  makes  a  list  containing  that  atom, 
returns: 

"Working  memory  defined." 


19 


see  section  3. 


20 


see  section  2 


mode 

form:  (mode  <speci.il  module  n.nne>) 
argument's:  \  piedel'med  special  module 
s>  mipsis: 

I  o.ids  in  .1  Npeei.il  module.  ( i  R  AIM  S  '.ci'Meii  4  offers  .1  I  I  SI’  module, 
w  Inch  com, mis  CiR  \l’l  S  s  mieni.ii  know  ledge  of  I  ISP 
programming.  \ersion  3  of  the  interpreter  offers  .1  learning  module, 
described  111  later  sections.  In  \ersion  5.  if  the  command 
(sell'  <"i< ’iluics}/  is  issued.  <moduks>  will 

become  the  new  list  of  accessible  external  packages.  I  he  learning 
module  is  one  such  module  which  has  been  added, 
returns: 

"O.K." 

7.2.  Starting  and  Stopping  the  System 

SUt.C 

form:  (start  [goal  [working-memory])) 

arguments:  The  goal  defaults  to  the  u 'p-^oal  and  working  memory 

defaults  to  nil.  which  assumes  the  current  working  memory. 

synopsis: 

The  start  command  begins  running  the  production  set  in  die  context 
of  the  gi\en  goal  and  w  ith  the  given  working  memory.  The  goal  may 
be  any  goal  which  has  been  defined  by  the  system  (or  the 
top-goal).  If  the  given  goal  is  a  list,  then  (setgoal  goal)  is 
performed  automatically.  If  wm  is  non-nil.  then  (setwm  wm)  is 
performed  automatidiy. 
returns: 

An  error  indicating  that  the  top-goal  was  never  defined  or  (after 
running  die  production  system)  a  message  indicating  the  success 
or  failure  of  the  top-goal. 

stop 

form:  (stop) 
arguments:  none 
synopsis: 

Stops  the  production  system  from  running  and  returns  the  user  to 
the  top  level  of  die  GRAPHS  interpreter.’1 . 
returns: 
nothing 

^This  lunclion  does  a  Fran/  l.isp  (reset) 


'<() 

exit 

form:  exit  or  (exit) 
arguments:  none 
x\  nopxis: 

I  he  exit  command  is  used  to  Ic.oe  the  Cilx  \I’I  S  s.stem.  I  his  command 
must  he  typed  .it  the  top-lexel"  . 
returns: 

nothing  (it  never  returns) 

7.3.  Restarting  the  System 

g reset 

form:  (greset) 
arguments:  none 
synopsis: 

The  greset  command  clears  tire  goal  structure  and  sets  the  top  goal 
to  that  which  was  given  in  the  last  call  to  sctgoal. 
returns: 

A  message  concerning  the  success  or  failure  of  the  call. 

wmreset 
form:  (wmreset) 
arguments:  none 
synopsis: 

The  wmreset  command  sets  the  contents  of  working  memory  to  that 
given  in  the  last  call  to  setwm.  If  no  call  to  setwm  has  been  given, 
then  working  memory  is  cleared, 
returns: 

"Working  memory  defined." 

preset 

form:  (preset) 
arguments:  none 
synopsis: 

The  preset  command  deletes  the  current  production  set.  To  start 
another  production  run.  the  slurp  command  must  be  used, 
returns: 

"O.K." 

clear 

^not  dunng  a  production  run  •  use  stop  for  that  purpose 


d 


form:  (dear) 
arguments:  none 
s>  nopsis: 

I  he  dear  command  rcmoses  the  production  ■set  from  the  cm.  tionmcnt. 
and  deletes  both  the  goal  'trucluie  and  work.ng  mentor..  I  has 
et'inmaitd  does  not  disable  eteset  or  wm reset  from  vihagmg  the 
previous  top  goal  or  working  memory, 
returns: 
okay 

7.4.  Printing  Useful  Information 

PP 

form:  tpp  |produetion-name]) 

arguments:  A  legal  GRAPHS  production  name  currently  defined  to  the  system 
or  no  arguments. 

synopsis: 

Pretty  prints  a  production  to  the  terminal.  The  form  used  in  pretty 
printing  is  the  form  which  the  system  is  internally  using  (not 
simph  a  copy  of  the  input  production  specification).  This  function 
ts  useful  to  new  GRAPHS  users  who  arc  not  familiar  with  GRAPHS'* 
standard  production  fonn.tt.  Productions  do  not  have  to  be  in  tlnis 
form,  but  they  arc  much  easier  to  read,  and  they  make  it  easier  for 
interaction  between  GRAPHS  programmers.  This  function  will  print 
out  all  of  the  productions  currently  defined  if  given  no  arguments. 
Returns:  . 

The  pretty  printed  production(s). 
ppwm 

form:  (ppwm) 
arguments:  none 
synopsis: 

Pretty  prints  the  contents  of  working  memory  in  the  form: 

"WORKING  MHMORY:  ” 
torments  of  working  memory > 

"END" 

returns: 

END 

ppeurrentgoal 
form:  (ppeurrentgoal) 
arguments:  none 
synopsis: 


<8 


I’rott  v  pi  i ni-s  the  eui  rent  goal, 
returns: 

"endgo.il" 

ppiopaiul 

form:  (pptopgoul) 
arguments:  none 
synopsis: 

Pretty  prints  the  top  goal, 
returns: 

'endgoal” 

ppgoal 

hum:  ( ppgoal  (goal|) 
arguments:  none  or  a  goal  name 
synopsis: 

Pretty  prints  the  gi\en  goal.  If  no  goal  is  given,  the  system  tries 
to  print  the  eurrent  goal.  If  no  current  goal  is  defined,  then  it 
will  try  :o  prim  the  top  goal.  If  the  top  goal  is  not  defined, 
then  an  error  is  returned  and  no  goal  is  printed, 
returns: 

"endgoal” 


8.  Debugging 

Pioduction  vts  rarely  ^ 1 1 H o : i  correctly  the  fust  mno  through.  I  i-r  tlm  reason.  GK  M’l  S  h.,>  .1  few 
useful  debugging  mechanisms.  When  uvd  m  conjunction  wall  the  tiucc  package.  pu  duc'uoti  systems  can  he 
interactively  debugged  with  the  mechanisms  given. 

Hxtcnstvc  documentation  mat  help  when  trying  to  keep  a  system  hug  tree.  I  he  GRAPHS  comment 
characters  are  the  curl;,  brackets  ! }.  Ain  characters  found  between  a  set  of  curb  brackets  will  he  ignored  b> 
the  GRAPHS  interpreter. 

8.1 .  About  the  Monitor  and  QUIET  Mode 

1  he  GRAPHS  monitor  is  entered  when  die  GRAPHS  system  is  loaded  into  1  ISP.  The  system  runs 
embedded  in  die  Hr.in/  MSP  environment.  However,  the  monitor  traps  all  commands  and  checks  to  sec  if 
they  are  legal  GRAPHS  function  calls  (these  are  listed  tn  Appendix  1).  1  egal  GRAPHS  commands  with  no 

"'I 

arguments  can  be  typed  as  atoms’  .  The  QL'IKT  function  turns  off  function  checking  so  that  l.ISP  commands 
can  be  used.  Some  GRAPHS  commands  go  by  the  same  name  as  certain  LISP  functions.  These  functions 
cannot  be  accessed.  For  instance,  help  gives  help  on  GRAPHS  not  on  l.ISP.  I  oaJ  must  be  used  instead  of 
slurp  and  old-pp\\  must  be  used  instead  of  pp~*  . 

8.2.  Breaking 

At  any  time  the  user  can  type  eontrol-C.  This  is  handled  as  an  interrupt  and  can  be  continued  with  the 
command  go.  The  user  can  break  from  a  break,  and  so  on.  Haeh  subprocess  is  stored.  The  last  suhprccess  to 
break  from  is  the  subproccss  which  is  restarted  when  go  is  typed. 

breaking  can  be  used  extensively  in  debugging,  when  goals,  working  memory,  and  productions  might  need 
to  be  printed  in  the  middle  of  a  production  run.  Breaking  can  also  be  set  automatically  with  the  iracc  package 
(see  section  9). 


see  section  7 

Ws  command  is  used  lor  produclion  pretty  priming 


8.3.  GRAPES  Debugging  Commands 

\ll  Ci l<  \PKS  debugging  commands  are  time! ions  w  nil  :u>  arguments.*6. 

eset  I  his  function  returns  the  etirreni  comliet  set  (in  list  form).  I  he  conflict  set  is  .1  list  of  the 

n.iines  of  the  instantiations  winch  will  undergo  conflict  resolution.  If  .1  p.iriicului 
production  had  more  than  one  possible  instantiation,  several  copies  of  the  production 
name  might  be  in  the  list.  I  lie  eset  command  is  good  for  analyzing  what  productions 
competed  for  a  match  to  the  current  working  memory  and  goal  memory."6 

resolve  This  function  traces  the  conflict  resolution  process  responsible  for  picking  the  current 

production.  If  recency  was  used  in  deciding  among  competing  productions,  die  recency  of 
all  the  working  memory  items  matching  each  production  will  be  pretty  printed.  If 
specificity  was  also  used,  the  summed  specificity  of  each  production  w  ill  be  displayed.  If 
neither  strategy  singled  out  one  production,  a  message  is  primed  saying  that  die  conflict 
was  resolved  through  a  random  choice*7. 

bindings  When  a  particular  instantiation  is  decided  upon,  its  bindings  can  be  displayed  using  the 

bindings  command.  This  prints  die  list  of  variables  in  the  production  followed  by  die  value 
which  die  variable  matched.  During  the  matching  pnKess.  the  variable  may  have  bound  to 
several  possible  configurations  of  values.  Only  the  final  bindings  of  die  variables  arc 
shown. 


^ihus  they  can  be  typed  without  the  parenthesis 

26  . 
see  section  5 
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section  5  has  more  details  on  the  conflict  resolution  strategies 


4! 


9.  Special  Packages 

I  he  ( >K  M'l  S  •iiiotputci  iikhiucs  .1  ii.wc  package  .i  'Mc.ik  pack-ice  and  .t  photo  package.  Since  the  break 
package  .iru!  the  ir.ii.>-  p.  vk.iec  ate  -iced  together  dies  ■■'.I'  be  dev.  n  bed  together.  I  lion,  the  photo  package 
Will  be  MlttodllcVd. 

9.1 .  T racing  and  Breaking 

lull  goals  and  productions  can  Ke  traced.  The  productions  arc  traced  when  die;,  lire,  and  die  goals  arc 
traced  when  dies  become  the  current  goal.  A  sample  trace  is  chosen  on  the  following  page. 

I  his  trace  shows  a  lnpouietie.il  production  run  m  which  both  goal  tracing  and  production  tracing  arc  used. 

■>0 

1  he  "I  |"  symbols  indicate  the  depth  in  die  goal  tree.  "5"  is  the  tiring  number"  .  "Lsc-hand-coding- 
know  ledge"  is  the  name  of  the  current  production,  and  "goal-1"  is  the  name  of  die  current  goal.  All  tests 
against  working  manors  and  goal  memory  are  shown,  with  the  values  they  bound  to.  I  .ISP  calls  on  the 
left-hand  side  are  shown  before  evaluation.  The  right  hand  side  actions  are  also  shown.  Methods  attached  to 
goals  are  given,  \ddiiions  and  deletions  from  working  memory  are  also  shown.  The  evaluations  of  user 
functions  are  shown  if  they  return  a  GRAPHS  pattern,  otherwise  dies  do  not  show  up  on  die  trace.  Goals 
inserted  into  random  places  in  the  tree  arc  listed  separately  from  "ordinary"  subgoals.  The  immediate 
su  pereoai  and  die  immediate  subgoals  of  each  inserted  goal  are  also  listed.  If  a  goal  is  redone,  the  tracer  shows 
the  goal  tree  structure  leading  to  that  goal.  The  goal  parameters  of  any  goal  arc  also  uaced  (in  die  example 
these  would  be  "action"  and  "argument".  All  variables  arc  replaced  by  die  values  to  which  they  bound. 

V 

9.1.1.  Starting  the  T race 

The  default  trace  includes  only  the  firing  number,  the  production  name,  the  goal  name,  and  die  depth 
markers.  All  other  options  can  be  set  w  ith  the  following  two  commands: 

ptracc 

form:  (ptracc  [  /switchl  [  /sw  itch2  ....  ]]  [pnumcl  [pnamc2  ... )] ) 
arguments:  A  set  of  switches  and  a  set  of  productions 
synopsis: 

Performs  a  production  trace  on  the  given  productions.  If  no 
productions  arc  given,  then  all  productions  arc  traced.  Switches 
arc  optional  and  apply  to  all  production  names  which  follow  them. 

Switches  can  be  made  to  apply  to  only  selected  productions  by 
enclosing  the  switches  and  the  production  in  parenthesis. 
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simply  the  number  of  productions  which  have  fired  so  far 


goal  - 1 

action:  solve-by-hand 
arg:  0ref i ned-resu  1  tl 
endGoal 

|  5)  use- hand-coding-know  ledge 

|  .  TESTS: 

j  .  ( has-rel ation  resultl  (all  path-from)  (start)) 

|  .  METHOD: 

|  hand-search, 

j  .  INSERTED  into  wm : 

(  .  (has-relation  terml  member  (listl)) 

j  .  (policy  ( avoid-repeats  ref i ned- resu 1 1 1) ) 

j  .  REMOVED  from  wm : 

j  .  (has-relation  resultl  (all  path-from)  (start)) 

|  .  SUBGOALS  created: 

I  (goal-5 

j  .  (action:  make-by-hand 

(  .  arg:  list2 

j  .  value:  (start))  ) 

I  •  (goal-6 

|  .  (action:  repeat-until-failure 

j  .  condition:  @goal2 

j  .  do:  0goal3)  ) 

j  .  INSERTED  into  goal  tree: 

j  .  (0goal2 

j  .  (action:  find 

j  arg:  terml 

j  .  constraint:  (not  tried))  ) 

|  .  Subgoal  of:  goal-6, 

j  .  (@goa!3 

j  .  (action:  perform-operations 

j  .  args:  (0goal4  0goal5))  ) 

j  .  Subgoal  of:  goal-6, 

j  .  Subgoals  are:  (@goal4  @goal5). 

j  endProduct i on 

Figure  9-1:  A  Sample  Production  Trace 


4.1 


If.i  production  trace  is  in  effect,  all  information  about  the 
production(s)  is  printed, 
returns: 

A  list  of  all  productions  being  traced. 


g  trace 

form:  (gtrace  [  /switch!  [/switch?  ...  )|  [action  1  [action2  ...  ]] ) 
arguments:  A  set  of  sw  itches  and  set  of  goal  actions, 
synopsis: 

Performs  a  goal  trace  on  all  goals  with  the  gnen  actions.  If  no 
actions  are  gisen.  then  all  goals  are  traced.  Switches  are  treated 
the  same  way  as  in  production  tracing.  If  a  goal  trace  is  in 
affect,  all  information  about  the  goal(s)  is  printed, 
returns: 

A  list  of  all  goal  actions  being  traced. 

9.1 .2.  Stopping  the  Trace 

If  tracing  is  no  longer  desired,  it  can  be  turned  off  w  ith  die  following  commands: 

pun  trace 
form:  (puntracc) 
arguments:  none 
synopsis: 

Returns  production  tracing  to  die  default  mode  (only  production 
names  and  firing  numbers  printed), 
returns; 

A  compact  list  of  all  productions  untraccd. 

guntracc 
form:  (guntrace) 
arguments:  none 
synopsis: 

Returns  goal  tracing  to  the  default  mode  (only  goal  names  and  depth 
markers  printed), 
returns: 

A  compact  list  of  all  goal  actions  untraccd. 
untracc 

form:  (untracc  namcl  [namc2  [namc3  ...][ ) 

arguments:  Hach  name  is  either  a  production  name  or  a  goal  action. 

synopsis: 

Untraccs  select  goals  and  productions. 


returns: 
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"O.K." 

9.1.3.  Trace  Switches 

Ku.li  u. ico  command  c.111  sol  a  number  of  switches.  I  hose  switches  loll  the  iraco  i  lire  when  to  perform 
certain  (I, icon  and  when  to  perform  a  break. 

/break  1 

Does  a  break  just  before  a  production  tires.  A  message  like: 

break  before  production  <pname>. 

I  >pe  go’  to  continue. 

[BREAK  <n>] 

will  be  printed.  Where  <pname>  is  die  production  being  traced,  and  <n> 
is  tlie  current  break  le\ e!  (see  section  8.2).  l-acli  time  the  given 
production  or  productions  fire,  a  break  is  executed. 

/break  2 

Does  a  break  just  after  a  production  fires.  It  is  used  the  same  way  as  the 
/break  1  switch.  A  message  will  be  printed  like 

break  after  production  <pname> 
type ’go’ to  continue. 

(BREAK  <n>] 

/break 

Sets  break-points  at  the  given  goals  if  a  "gtracc"  is  being  done.  Sets 
break-points  both  before  and  after  the  given  productions  if  a  '’ptracc" 
is  being  done. 

/after 

The  /after  sw  itch  is  used  to  state  that  tracing  is  not  to  begin  until  a  given 
production  has  fired.  For  example, 

(ptracc  /after  p5) 

will  trace  all  productions,  but  only  after  p5  has  fired.  If  the  argument 
to  /after  is  a  list,  then  tracing  will  begin  after  any  one  of  die  given 
productions  has  fired. 

/until 

The  /until  switch  is  similar  to  the  /after  switch,  except  it  specifics 
that  tracing  is  to  halt  when  one  of  the  given  productions  fires.  It  is 
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useful  in  conjunction  with  the  /.liter  switch.  For  ex.implc. 

(gtrace  /.liter  p5  /until  (p7  pS)) 

will  truce  .ill  coals  as  soon  as  p5  lires.  and  will  discontinue  tracing 
when  either  p?  or  p8  tires. 


9.2.  Photo 

The  photo  package  records  a  GRAPHS  session.  The  photo  tile  will  contain  all  interaction  with  GRAPHS 
from  the  time  the  />/.'< >/o  command  is  issued  to  the  time  die  unplmio  command  is  issued.  The  photo  file  is 
automatical!)  terminated  when  GKAI’f  S  is  exited.  Nested  pholo  sessions  arc  not  allowed.  !'hc  photo 
commands  arc  given  here: 

photo’ 

form:  ( photo  [lilenamcj  ext)]) 
argument:  A  legal  tile  name 
synopsis: 

Writes  all  output  to  the  giicn  file.  The  default  file  extension  is 
".log",  and  the  default  file  name  is  "photo".  For  example, 

(photo  test) 

would  send  all  output  to  a  file  named  "tcst.log". 
returns: 

"PHOTO  recording  initiated:  <filcname>" 

unphoto 

form:  (unphoto) 
arguments:  none 
synopsis: 

Stops  recording  the  GRAPES  session, 
returns: 

"PHOTO  recording  terminated." 

The  trace  package  and  the  photo  package  interface  nicely,  so  that  traces  of  production  runs  can  be  recorded 
in  full  detail. 


♦ 
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10.  Learning  Mechanisms 

Hi  IS  section  oi'  the  document  describes  how  to  use  the  C  j  Is  \  PIS  learning  median  isms  to  acquire  new 
productions,  I  his  f.icihu  is  only  offered  in  GR  \  1 M  S  \eision  5. 

I  here  are  two  types  of  learning  mechanisms  currently  available  to  GRAPHS  users.  Iltese  arc  composition 
and  proccduraUzation.  (  uoipusitwn  involves  collapsing  productions  which  fired  at  goals  in  a  given  section  of 
the  goal  tree.  Proceduralization  reduces  the  number  of  long-term  manors  retrievals  made  on  a  production 
left-hand  side.  Together  composition  and  proceduralization  form  compilation.  This  section  docs  not  intend  to 
cover  all  the  aspects  of  the  GRAPHS  learning  mechanisms.  However,  many  useful  learning  production  sets 

*1Q 

can  be  written  with  the  material  presented  here*  . 


10.1.  Proceduralization 

The  GRAPHS  proceduralization  mechanism  follows  John  Anderson's  ACT  model  quite  closely.  In 
GRAPHS,  as  in  ACT.  knowledge  is  found  in  two  separate  and  fundamentally  different  forms.  The  first  type  of 
knowdedge  is  declarative  knowledge. knowledge  about  facts,  which  is  stored  propositionally.  The  second  type 
of  knowledge  is  procedural  knowledge,  knowledge  about  processes,  which  is  stored  as  production  rules. 
Declarative  knowledge  can  be  in  long-term  memory  or  in  working  memory.  In  the  ACT  model,  working 
memory  is  die  active  part  of  long-term  memory.  In  GRAPHS,  the  memory  elements  do  not  have  associated 
activation  levels,  so  the  user  must  specify  exactly  what  propositions  are  in  long-term  memory  and  which  arc  in 
working  memory.  The  items  in  long-term  memory  arc  a  subset  of  the  items  in  working  memory.  Productions 
can  only  add  to  working  memory  and  goal  memory.  Long-term  memory  items  are  added  using  the  "setwm” 
command.  Long-term  memory  is  not  destroyed  between  production  runs,  so  knowledge  can  be  accumulated, 
making  learning  modelling  easier. 

10.1.1.  Interpretive  Productions 

When  procedures  have  not  been  encoded  as  production  rules,  they  reside  in  memory  in  die  form  of 
declarative  procedures.  Productions  which  access  declarative  procedures  arc  said  to  be  interpretive.  These 
interpretive  productions  work  over  a  large  range  of  circumstances  and  tend  to  be  very  general.  However, 
long-term  memory  retrieval  is  very  slow,  so  using  interpretive  productions  can  be  costly  in  any  information 
processing  system.  Proceduralization  provides  a  way  of  reducing  a  production's  access  to  long-term  memory 
by  building  The  long-term  memory  information  into  the  production  directly.  In  die  current  implementation, 
proccduralizcd  productions  are  matched  before  other  produedons,  producing  an  obvious  speedup  in 
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see  appendix  three  for  a  more  detailed  description  of  the  learning  parameters 
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execution  time.  In  addition,  procedurali/ed  productions  faster  to  match  since  they  contain  less  left-hand  side 
tests  than  their  corresponding  interpretive  versions.  Note  that  procedurali/ed  productions  will  fire  in  place  of 
the  original  productions  under  the  appropriate  circumstances.  However.  the  original  interpretive  productions 
are  still  available  to  the  system  in  situations  where  no  procedtiraii/ed  rules  are  applicable. 


10.1.2.  Finding  What  to  Proceduralize 

The  GRAPHS  procedurali/ation  mechanism  is  invoked  automatically  when  the  parameter  learning- now  is 
set  to  "t" All  productions  which  access  long-term  memory  fall  prey  to  the  proceduraii/ation  mechanism.  A 
production  is  not  procedurali/ed  if  it  involves  setting  goals  whose  action  specifics  planning,  i  hose  goals  which 
involve  planning  must  he  defined  by  the  usei  (though  some  default  values  exist).  In  GRAPHS  it  is  assumed 
that  productions  which  set  goals  to  plan  are  fundamentally  interpretive  in  nature  and  should  not  be 
procedurali/ed. 


10.1.3.  Forming  Special  Case  Rules 

If  a  production  has  been  chosen  to  be  proccdurali/.ed.  its  last  successful  instantiation  is  retrieved  and 
searched  for  test.,  against  long-term  memory.  Hach  variable  which  bound  to  a  proposition  in  long-term 
memory  or  part  of  a  proposition  in  long-term  memory  is  replaced  by  the  object  that  it  bound  to.  This 
incorporates  the  information  contained  in  the  instantiation  directly  into  the  new  production.  A  host  of  special 
case  rules  can  be  formed  this  way.  Note  that  variables  arc  replaced  on  both  the  right-hand  and  left-hand  sides. 

10.1.4.  Production  Strength 

GRAPHS  version  5  possesses  strength  classes.  Each  production  has  an  associated  strength  value  (whose 
default  is  1.0).  Productions  in  the  highest  strength  class  are  matched  first.  If  none  of  these  productions  match, 
the  next  strength  class  is  considered.  This  procedure  is  repeated  until  all  successful  matches  within  a  strength 
class  have  been  found,  or  until  there  arc  no  more  productions  left  to  match.  When  a  production  is 
proccdurali/cd,  its  strength  becomes  greater. 

10.2.  Composition 

The  GRAPES  composition  mechanism  collapses  pieces  of  the  goal  tree  to  form  a  plan  for  doing  some  large 
action.  The  user  has  control  over  which  pieces  of  the  goal  tree  he  wishes  to  include  in  the  composition  process. 

Before  loading  a  production  set,  the  user  must  set  some  learning  parameters  which  tell  the  system  which 
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productions  to  compose  and  when  to  compose  them.  These  parameters  cun  he  set  using  'he  setp  commond 
(see  section  on  parameters). 


10.2.1 .  When  to  Compose 

The  learning-ae lions  parameter  holds  a  list  of  actions  which  tell  GRAPHS  when  to  start  composing.  \\  hen  a 
goal  with  a  learning  action  is  popped  as  a  success.  GRAM'S  examines  the  goal  tree  beneath  the  goal  for 
possible  compositions.  If  a  learning  action  goal  is  declared  successful,  it  signifies  the  completion  of  a  problem 
or  a  subproblem. 

10.2.2.  Where  to  Start 

The  flag-actions  parameter  is  set  to  a  list  of  actions  which  tell  GRAPHS  where  to  start  composing.  Goals 
with  flag  actions  specify  a  task  which  needs  to  be  accomplished.  These  goals  are  called  composition  headers. 
The  group  of  productions  which  tired  at  goals  beneath  die  composition  header  form  a  macro-operator  for 
performing  the  specified  task.  The  composition  mechanism  will  combine  this  group  of  productions  to 
produce  a  single  rule  w  hich  has  the  effect  of  the  group  and  therefore  accomplishes  the  uisk. 

10.2.3.  Where  to  End 

The  non- learned- actions  parameter  holds  a  list  of  actions  which  tell  GRAPHS  where  to  stop  composing. 
These  goals  often  involve  checking  and  re-  examining,  so  dies  arc  automatically  set  as  subgoals  on  the 
right-hand  side  of  the  composed  production. 

GRAPES  must  have  a  way  to  link  the  macro-operators  together  to  accomplish  a  sequence  of  tasks.  The 
composition  mechanism  sets  each  composition  header  goal  as  a  subgoal  on  the  right-hand  side  of  the 
preceding  composed  production.  In  this  way.  one  macro-operator  can  set  a  goal  which  will  be  performed  by 
another  macro-operator. 

10.2.4.  The  Composed  Left-Hand  Side 

Productions  which  have  been  chosen  for  composition  can  have  various  pieces  of  their  left-hand  sides 
included  in  die  final  composed  production.  All  tests  against  w-orking-memorv  arc  included  unless  dicv 
matched  against  an  dement  inserted  by  another  production  in  the  group  being  composed.  Likewise,  all  goal 
tests  arc  included  unless  dicy  match  to  goals  in  the  group  being  collapsed.  This  group  of  goals  is  called  the 
goal  block.  User  function  tests  arc  only  included  in  die  left-hand  side  of  die  composed  production  if  dicir 
component  parts  arc  not  part  of  any  working-memory  clement  added  by  productions  in  the  group  being 
composed.  Parameters  for  the  composed  production  arc  exactly  those  which  matched  die  specification  for  the 
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composition  header  goal. 

10.2.5.  The  Composed  Right-Hand  Side 

I  ha  right-hand  side  of  the  composed  production  contains  ail  actions  relevant  to  performing  the  usk 
specified  In  the  composition  header  goal.  In  general,  all  additions  to  working  memory  are  included  and  ail 
additions  to  the  goal  tree  calls  to  I  ISP  are  not  included.  A  goal  addition  is  included  if  it  is  a  mm-U  orn,  ./  goal 
or  a  specification  of  a  new  task,  both  described  abuse.  Goals  which  score  inserted  outside  of  the  goal  block  arc 
also  included. 

Function  calls  arc  included  in  the  composed  production  if  the  function  is  on  die  pin  swal- user fum  nous  list. 

I  hesc  functions  usually  perform  operations  on  an  external  memory*1. 

If  a  production's  action  is  a  member  of  the  phinning-.u-tiuns  list,  ns  right-hand  side  is  not  included  in  the 
composed  production's  right-hand  side.  Planning  productions  arc  only  concerned  with  intermediate  results, 
not  crucial  to  the  action  of  the  macro-operator. 

10.2.6.  Changes  in  the  Production  Appearance 

1  ho  composition  process  makes  some  changes  in  the  patterns  which  are  finally  included  in  the  macro¬ 
operator.  String  variables  are  replaced  by  equivalent  sequences  of  regular  variables.  Variables  arc  renamed  in 
a  consistent  way  across  elements  in  the  composed  production's  left-hand  side.  A  variable  is  replaced  by  its 
binding  if  die  binding  appears  as  a  constant  in  another  mat.ch  element.  On  die  action  side  of  the  composed 
production,  ‘mapstcre  and  ‘mapgoafs  arc  replaced  by  sequences  of  working-memory  and  goal  elements. 
Finally,  if  compilation  is  taking  place,  proceduralization  will  take  effect  before  composition,  deleting  some 
elements  from  consideration  before  composition  begins. 

Successful  use  of  die  GRAPHS  learning  mechanisms  is  dependent  on  how  well  die  component  productions 
arc  written,  and  how  intelligently  the  learning  parameters  arc  set.  If  both  arc  done  well,  new  and  useful 
production  rules  result. 
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10.3.  An  example  of  learning 

Ihis  example  shows  how  .1  simple  goal  nee  .aid  set  oi  prodi  .ii.'iis  ..in  lie  used  to  pn oedui'.ili/e  and 
compile  new  pioducnons. 


I  he  coal  tree: 


top-goal 
action:  wrlta 
function:  second 
args:  11st3 
output:  1 istl 


goal-1 

action:  code-relation 
function:  second 
arg:  llstl 


goal-2  goal-3 

arg:  811sl  arg:  llstl 


I'he  working-memory: 


( has-rel atlon  llstl  second  11st3) 
( cal cul ated-Dy  first  car) 
(caiculatad-by  end  edr) 

(Isa  11st3  function-argument) 


The  lone-term  memory: 


( cal cul ated-by  first  car) 
( cal cul atad-by  end  edr) 


The  parameter  settings: 


fldg-actlon* 
learning-actions 
non-1 earned- actions 
planning-actions 
physical -user-functions 


(code-relation) 

(•rite) 

0 

0 

0 


The  productions: 
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(p  write-function 
action:  write 
function:  "function 
args:  *arg 
output:  “output 

tests:  (has-rolatlon  “output  -function  ■ ar g ) 

••> 

(goal 

(action:  code-relation 
relation:  “function 
arg:  “output))) 

(p  find-second 

action:  code-relation 
relation:  second 
arg:  “11s 
tests : 

(has-rel at  Ion  “11s  second  -result) 

( has-rel atlon  -11s  first  *11s2) 

( has-rel atlon  • 1 1 s 2  end  -result) 

(goal 

(action:  get-function 
arg:  • 1 1 s2 ) ) 

(goal 

(action:  get-function 
arg:  -11s))) 

(p  see-car 

action:  get-function 
arg:  -arg 

tests:  (has-rel atlon  -arg  first  -result) 
(calculated-by  first  -function) 
(calculated-by  -result  -expr) 

»•> 

(calculated-by  -arg  (-function  -expr)) 

(•pop  success)) 

(p  found-cdr 

action:  get-function 
arg:  -arg 

tests:  (has-relatlon  -arg  end  -11s) 

(Isa  -11s  function-argument) 
(calculated-by  end  -function) 

••> 

(calculated-by  -arg  (-function  -11s)) 

(•pop  success)) 


The  GRAPES  am  of  this  environment,  using  the  learning  mechanisms: 

[*]  (mode  learn) ;  The  learning  module  must  be 
;  loaded  before  the  production  set 

O.K. 

[*]  (slurp  example) 


write- function 
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lind-scamd 

'.co-car 

h'Ulld-OiJr 


•••  l  op  01  >.il  defined.  •** 


***  Working  and  Long  l  orm  Memories  dot’inod.  *** 
***  Paramcter(s)  Sol.  *** 

Production  l-nwronment  Defined. 

[*]  ptracc 

w  rite- function 
fmd-sceond 
see-ear 
found-cdr 

[*|  gtracc 

^  rite 

code- relation 
get-function 

[*]  start 

top-goal 
.  action:  write 

function:  second 
.  args:  !ist3 
.  output:  listl 
endGoal 

|  1)  write-function.  [1] 

|  .  TESTS: 

|  .  (has-rclaiion  listl  second  Lst3) 

|  .  SUBGOALS  created: 

I  •  (goal-1 

|  .  (action:  code-relation 
|  .  relation:  second 

|  .  arg:  listl) ) 

|  cndProduction 


go.ll-1 

.  action:  code-relation 
iclation:  second 
arg:  listl 
endGoal 

|  2)  rind -second.  [1J 
|  .  IKS  IS: 

|  .  (lias-relation  listl  second  list3) 
|  .  INSKIM  HI)  into  #m: 

|  .  (bus-relation  lisil  first  (d lisl) 

|  .  (lias-relation  (d  lisl  end  listi) 

|  .  SL  IKjO  M  S  created: 

I  .  (goal-2 

|  .  (action:  get-function 

|  .  arg:  (d  lisl) ) 

|  .  (goal-3 

|  .  (action:  get-function 

|.  arg:  listl)) 

|  endProduction 


goal-2 

.  action:  get- function 
arg:  (d  lisl 
endGoal 

|  3)  found-edr.  [1] 

|  .  TESTS: 

|  .  (has-rclation  ©lisl  end  !ist3) 

|  .  (isa  lisr’ function-argument) 

|  .  (calculatcd-by  end  edr) 

|  .  INSERTED  into  wm: 

|  .  (calculatcd-by  <?!lisl  (edr  list3)) 
|  endProduction 
Goal  successful. 

goal-3 

.  action:  get-function 
arg:  listl 
endGoal 
|  4)  see-ear.  [1] 


|||.  I  I  SIS: 

|  |  |  .  (has- relal  urn  list  1  first  ("list) 

|||.  lealculated  In  first  car) 

|||.  (calculatcd-by  ("  lisl  (eJr  list.?)) 
|||.  INSI  R  1 1  I)  into  »m: 

|||.  (calculatcd-by  list  1  (ear  (cdr  list3 ))) 
|  |  |  endProduction 
|  |  Goal  successful. 

|  Goal  successful. 

Goal  successful. 

Defining  Procedurali/cd  Production: 
prc-found-g-2-  L: 

(p  prc-found-g-2- 1  2.0 
action:  get-function 
arg:  =arg 
tests: 

(has-rclation  =arg  end  =lis) 

(isa  =  lis  function-argument) 

(calculatcd-by  =  arg  (cdr  =  lis)) 

(*pop  success) ) 

Defining  Procedurali/ed  Production: 
prc-scc-g-3-2: 

(p  prc-scc-g-3-2  2.0 
action:  get-function 
arg:  =arg 
tests: 

(has-rclation  =nrg  first  =  result) 
(calculatcd-by  =  result  =cxpr) 

(calculatcd-by  =arg  (car  =  expr)) 

(‘pop  success) ) 

Defining  Composed  Production: 
comp-find-g-1-3: 


(p  comp-find-g- 1  ]  2.0 
action:  code-relation 
relation:  second 
arg:  =  hs2 
costs: 

(has-relation  -hs2  second  =  icsultl ) 

(isa  =  result  1  function-argument) 

(has-relation  =lis2  first  =  @lisll) 

(has-relation  =  (dlisll  end  =  result!) 

(ealculated-by  =  (<fhsll  (edr  =  result  1)) 

(caleulatcd-by  =  !is2(car(cdr  =resultl))) 

(*pop  success) ) 

HM>-  Top  Goal  Successful. 

Notice  that  the  last  rule  is  a  compiled  rule.  The  GRAPHS  learning  mechanisms  do  compilation,  rather  than 
pure  composition  as  a  default  learning  strategy.  The  compiled  rule  above  states  that  if  you  want  to  get  the 
second  element  of  a  list  and  the  list  is  a  function  argument,  use  the  cur  of  the  edr-  of  the  list32. 
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Appendix  I 

Summary  of  System  Commands 


Command 

\  moments 

1  )esu  itnion 

bindings 

0 

Displays  the  variable  bindings 
for  the  current  production 
instantiation. 

clear 

0 

Removes  production  set  and  clears 
working  and  goal  memories. 

eset 

0 

Displays  tire  names  of  productions 
in  die  current  conflict  set. 

greset 

0 

Resets  the  top  goal. 

gtracc 

n 

Traces  all  goals  with  the 
specified  action  [All  goals). 

guntracc 

0 

Turns  off  all  goal  tracing. 

help 

n 

Displays  help  on  the  given  topic. 

If  no  arguments  arc  given, 
a  menu  is  displayed. 

mode 

1 

I  oads  in  the  module  associated 
with  the  given  name. 

photo 

1 

Records  a  terminal  session. 

PP 

1 

Pretty  prints  the  given  production. 

ppcurrcntgoal 

0 

Pretty  prints  the  current  goal. 

ppgoal 

Oor  1 

Pretty  prints  the  given  goal, 
[current  goal  -  top  goal]. 

pptopgoal 

0 

Pretty  prints  the  current  top  goal. 

ppwm 


0 


Pretty  prints  the  present  contents 
of  working  memory. 
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preset 

0 

Deletes  the  current  production  set. 

ptracc 

n 

Traces  die  given  productions. 

puntrace 

0 

Turns  off  production  tracing. 

resolve 

0 

Displays  the  strategics  used 
to  decide  on  the 

current  production  instantiation. 

setgoal 

1* 

Sets  the  top  goal. 

setwm 

1* 

Sets  working  memory  to 
the  argument  list. 

slurp 

n 

Reads  in  a  set  of 
production  files,  [prompts] 

start 

O.l.or  2* 

Sums  the  system  with 
the  given  goal  [top  goal] 
and  the  given  working  memory 
[present  wm]. 

stop 

0 

Stops  the  current  GRAPHS  run 
and  returns  to  the  top  level. 

unphoto 

0 

Terminates  the  current 
photo  session. 

untrace 

1 ..  n 

Stops  tracing  the  given  productions 
or  all  goals  with  the  given  action. 

wmreset 

0 

Resets  the  current  working  memory 
to  that  given  in  the  last  "setwm". 

Summary  of  Trace  Switches 

Switch  Arguments  Description 


/after 


n 


Sets  tracing  to  begin  after  a 
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production  or  production  list. 


/break 

n 

Sets  breakpoints  before  and  after 

a  set  of  productions,  or 

at  all  goals  with  a  given  action. 

/break  1 

n 

Sets  breakpoints  before 
a  set  of  productions. 

/break  2 

n 

Sets  breakpoints  after 
a  set  of  productions. 

/until 

n 

Sets  tracing  to  stop  after  a 
production  or  a  production  list. 

NOTH:  n  specifics  that  any  number  of  arguments  can  be  given.  "[  ]"  indicates  a  default  value.  indicates 
that  function  evaluates  its  arguments  (functions  which  take  no  arguments  arc  not  ed). 
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Appendix  II 

Summary  of  User  Functions 


Command 

Areuments 

ysc 

Description 

•bind 

(var  value) 

L&R 

Explicitly  binds  <var> 

to  <valuc>. 

"current-goal 

none 

l.&R 

Gets  the  name  of  the 
current  goal. 

•gmethod 

([goal  [var]]) 

L 

Gets  the  method  of  <goal> 
and  binds  it  to  <var>. 

•input 

n 

R 

Binds  each  arg.  to  data 
read  in  from  the  terminal. 

•length 

n 

L.&R 

Creates  a  list  <n>  long 
of  unbound  variables. 

•mapgoal 

(var  list 
[res  goal-spec) 

R 

Successively  binds  <var>  to 
<list>,  creating  goals 
according  to  the 
<goal-spcc>.  Binds  result 
to  <rcs>. 

•mapstore 

n 

R 

Stores  each  expression  in 
working  memory. 

•match 

(pat  expr) 

L&R 

Tries  to  match 
<pat>  to  <cxpr>. 

•method 

([goal]  expr) 

R 

Sets  the  method  of 
<goal>  to  <cxpr>. 

•methodp 

([goal]  method) 

L 

Matches  the  method 
of  <goal>  to 
<mcthod>. 

•new 

(sym) 

L&R 

Creates  a  new  symbol 
which  looks  like  <sym>. 
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'output 

n 

R 

Prints  information 

to  the  terminal. 

'pattern 

n 

I.&  R 

Creates  a  pattern  out  of  its 
arguments. 

'pop 

(status) 

R 

Sets  current  goal’s  status  to 
<stattis>. 

'redo 

(goal) 

R 

Declares  <goal>  active. 

'remove 

n 

R 

Removes  the  working 
memory  element  from 
memory  which  matched 
the  <n>th  positive 
pattern  on  the  LHS. 

'subgoals 

(goal) 

L&R 

Get’s  the  subgoals 
of  <goal>. 

'success 

(goal) 

u  L 

Tests  if  <goal>’s  status 

is  success. 

'supergoal 

(goal) 

L&R 

Get’s  <goal>’s  immediate 
supcrgoal. 

Note:  Default  values  arc  not  given  here.  Sec  section  6.  for  a  more  complete  description.  Optional 
arguments  arc  given  in  "[  ]",  while  function  arguments  arc  given  in  "<  >"  when  referred  to  in  the  descriptions. 
n  means  that  one  or  more  arguments  are  possible.  I.  means  that  the  function  can  be  used  on  die  left-hand  side 
of  productions.  R  means  that  the  function  can  be  used  on  the  right-hand  side. 
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Appendix  III 

New  Functions  and  Changes 

\  number  of  changes  have  been  made  in  ihe  implementation  of  GRAI’I  S  \ersion  4.  I  hose  changes  do  not 
e fleet  the  performance  of  the  system  on  old  GRAPHS  programs.  I  he  following  functions  arc  simply  imply 
added  features  of  the  new  GRAPHS  interpreter: 

setwm 

Now  in  addition  to  having  a  working  memory.  GRAPHS  has  a  long-term 
memory,  long-term  memory  consists  of  copies  of  working  memory  items  which 
have  been  defined  by  the  user  to  be  of  long-term  status. 

To  put  something  into  long-term  memory  one  simply  precedes  it  with 
a  when  doing  the  setwm  command.  For  example:  (setwm  '((lias-relation 
john  father  rob)  *  (isa  John  man)))  w  ill  load  die  first  proposition 
into  working  memory  only  and  die  second  proposition  into  working 
memory  and  long-term  memory.  Long-term  memory  is  kept  between 
calls  to  setwm.  Long-term  memory  can  only  be  reset  by  doing 
(clear)  or  (exit)  commands. 


PP 

When  the  command  "(pp  learned)"  is  given,  all  learned  productions  arc 
printed  to  the  terminal. 

mode 

Learning  is  invoked  by  issuing  the  command  "(mode  learn)”.  This 
will  set  some  default  parameter  values.  Sec  the  parameter  list  for 
diese  defaults. 

show 

(show  <paramctcr>)  shows  a  parameter  and  its  current  value. 

(show)  prints  all  parameters  and  their  associated  values. 


setp 

(setp  <paramctcr>  <valuc>)  Sets  the  value  of  a  uscr-acccssiblc  parameter. 
Some  amount  of  type  checking  is  done. 

ppltm 

Prints  the  contents  of  long-term  memory. 


comp-p 

(comp-p  [goal  [file]])  Shows  a  production  composition  at  a  given  goal  and 
prints  results  to  a  file.  1'hc  goal  defaults  to  die  top-goal  and  the 
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file  defaults  to  the  terminal.  Hie  new  production  is  not  defined 
to  the  system. 

pre-p 

(pre-p  |goa!  [Il!e|])  Shows  a  production  proceduiali/aiion  at  a  gi\en 
goal  and  types  results  to  a  file.  Hie  goal  defaults  to  the  top-goal  and  the 
file  defaults  to  the  terminal.  I  lie  new  production  is  not  defined 
to  die  system. 

def-comp 

idefcomp  [goal  [file]])  Does  a  production  composition  at  a  given 
goal  and  prints  die  results  to  a  file.  The  goal  defaults  to  the 
current  goal  and  the  /lie  defaults  to  the  terminal.  The  new 
production  is  defined  to  the  system. 

def-pre 

(def-pre  [goal  [file]])  Docs  a  production  proccdurali/acion  at  a  given 
goal  and  prints  the  results  to  a  file,  flic  goal  defaults  to  the 
current  goal  and  the  tile  defaults  to  die  terminal.  The  new 
production  is  defined  to  the  system, 
empl-p 

(cmpl-p  [goal  [file]])  Does  a  proccdurali/ation  at  all  goals  beneath 
a  given  goal  and  composes  the  results.  The  final  production  is 
send  to  a  file.  The  new  production  is  defined  to  die  system,  though 
none  of  the  intermediate  proccdurali/ations  are  defined. 

‘compose 

(‘compose  [goal  (file)  goal ....  [)  Docs  an  explicit  production 
composition  from  the  right  hand  side  of  any  production.  Composes  at 
each  goal  in  the  argument  list.  When  a  list  is  encountered,  it  sends 
the  compositions  at  each  of  the  goals  following  to  die  file  name  in 
parentheses.  All  goals  must  exist  in  the  goal  tree  and  all  files  must  be 
able  to  be  opened  or  an  error  results,  fhc  goal  defaults  to  the 
current  goal  and  die  file  defaults  to  die  terminal. 

‘proccduralizc 

(‘proccduralize  [goal  (lile)  goal ...])  Docs  an  explicit 
proccdurali/ation  from  the  right-hand  side  of  a  production. 
Proccdurali/.cs  the  productions  which  tired  at  each  goal  in  the 
argument  list.  When  a  (ile  name  is  encountered,  it  sends  die 
procedurali/ations  at  each  of  the  goals  follow  ing  the  tile  name 
to  the  given  lilc.Fiic  names  must  be  in  parcnthcscse.  /\ll  goals 
must  exist  in  die  goal  tree  and  all  files  must  be  able  to  be 
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Appendix  IV 

User-Accessible  Parameters 

CIRAITS  version  5  has  a  set  of  parameters  v.lneli  are  available  in  the  user.  Parameter  settings  are  often 
made  in  the  same  file  which  holds  the  production  rules. 


special-modules 

A  LISP  association  list  whose  key  is  the  name  of  die  module 
and  whose  data  is  the  access-path  to  that  module.  The  default 
value  is  currently  ((learn  .  "s\s$sysdc\ice:[farrcll.comp] 
gleam. o")  (lisp  .  "sysSs\sdcviee:[farrell.comp]glisp.o")). 

default-strength 

A  real  number  representing  the  strength  for  the 
productions  whose  strength  is  not  given.  The  default 
is  1.0. 

cycle-trace 

This  is  a  list  if  three  possible  values,  which  specifics 
what  conflict  resolution  information  should  be  printed 
every  cycle.  When  "recency”  is  included  in  the  list  and  recency 
was  used  in  conflict  resolution,  time  tags  of  matching 
working  memory  elements  arc  display  ed.  If  "specificity"  is 
included  in  the  list  and  specificity  was  used  to  decided 
what  production  to  fire,  working  memory  and  goal  specificities 
will  be  displayed.  If  "randomize"  is  in  the  list  and  a  production 
is  chosen  at  random,  a  message  w  ill  be  printed  which  tells  that 
a  random  production  was  chosen.  The  default  value  for  this 
parameter  is  "nil",  which  means  that  no  conflict  resolution 
information  will  be  printed  on  every  cycle. 

uscr-acccssibie-parnmeters 

This  parameter  is  a  list  of  the  currently 
accessible  parameters.  The  default  value  is: 

"(planning-actions  special-modules  flag-actions 
non-lcarncd-actions  learning-actions 
uscr-acccssiblc-paramctcrs  physical-user- functions 
learning-now  producuoivcrcation-tracc 
default-strength  uscr-function-chcck  cycle-trace)". 

Notice  that  user-accessible- parameters  is  itself 
available  for  change.  This  facility  is  available 
so  that  die  user  can  give  himself  access  to  more 
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parameters.  I f"  [he  user  defines  .i  new  package  which 

has  coinc  global  variables  which  need  to  he  set. 

then  he  can  set  those  v.niahles  with  GK AIM  S  commands. 

production -creation- trace 

When  this  parameter  has  the  value  "t".  new  productions  will 
he  punted  as  thee  are  defined.  If  it  lias  the  value  "ml" 
they  w  ill  not  he  printed.  I  he  learning  module  assigns  this 
parameter  a  default  value  oft". 

planning-actions 

\  list  of  actions  whose  right-hand  sides  will  not  be  included 
in  the  composition  process,  t  hese  are  also  actions 
which  tug  a  production  as  fundamental!;,  interpretive. 

Planning  goals  often  involve  adding  intermediate  results 
to  working  memory,  and  often  match  on  long-term  information 
not  directly  connected  to  facts  in  the  task  domain.  It  is 
precisely  these  goals  which  when  collapsed  into  other  goals 
and  compiled  make  a  useful  plan  for  achicv  mg  a  given 
action. 

uscr-function-chcck 

This  parameter  is  to  protect  the  user.  When  set  to  "t" 
all  illegal  GRAPHS  commands  generate  an  error.  When  set 
to  "nil”,  tire  user  may  use  LISP  commands  also.  The  default 
value  is  dependent  on  the  version  and  site. 

physical-user- functions 

A  list  of  right-hand  side  user  functions  which  w  ill  always 
be  included  in  the  composition  process.  Usually  such  functions 
involve  making  a  change  in  an  external  memory.3'* 

non-leamcd-actions 

A  list  of  actions  for  goals  which  will  not  be  included  in 
the  composition  process.  These  are  usually  goals  which 
involve  checking,  which  must  be  done  all  of  the  time. 

The  compiled  production  will  set  a  goal  with  the 
"non-learned"  action.  Thus,  this  goal  should  be 
a  terminal  goal  in  the  piece  of  the  goal  tree  accessed 
by  the  composition  mechanism.  That  is,  goals  beneath 
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Sec  the  section  on  the  I.ISP  package  for  an  example  of  an  external  memory. 


(ho  goal  with  (ho  non-lcarned  action  will  not 
ho  included  in  tho  compiled  production. 
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flag-actions 

\  Iim  of  actions  tor  goals  which  will  he  onipns;ihm 
•u\;.h  oj.  Composition  headers  are  goals  which  arc  the 
U'P  goals  in  the  composed  Mock  of  the  goal  tree.  They 
signal  whore  to  start  composing. 

learning-actions 

\  list  of  actions  which  tell  the  system  when  to  begin  composing. 
W hen  a  goal  with  a  learning  action  is  popped  as  a  success, 
the  composition  mechanism  is  activated. 

learning-now 

T  his  parameter  becomes  "t"  when  the  learning  module 
is  loaded.  When  set  to  "nil",  the  system  w  ill  not  learn. 


71 


Appendix  V 

A  Sample  Production  Set 

1  ho  following  is  .1  production  sot  lor  the  I  o«or  of  I  l.moi  problem.  I  he  go.il  recursion  strategy  is  already 
coded  into  the  GRAIMS  architecture,  so  that  goal  bookkeeping  productions  are  not  needed.  Notice  that 
because  of  GRAPHS's  perfect  memory  for  propositions,  the  two  error  checking  productions  are  not  used.  If 
GRAPHS  produced  working  memory  failures  while  doing  this  problem,  the  last  two  productions  would  help 
keep  the  system  from  making  incorrect  moves. 

{  This  production  fires  when  a  single  disk  cannot  Be  moved.  The  goal 
must  Be  Broken  up  Into  sufiproBlems.  } 

(p  make- suBp rob  1 ems 
action:  move 
object:  -objectl 
to:  "pegY 
tests: 

(has-part  "objectl  "parti  -part2) 

(on  -part2  *pegX) 

(smaller-than  "parti  *part2) 

(Isa  "pegZ  peg) 

(•not  ("equal  "pegZ  «pegX)) 

(•not  (‘equal  -pegZ  "pegY)) 

••> 

(goal 

(action:  move 
object:  "parti 
to:  "pegZ) ) 

(goal 

(action:  move 
object:  «part2 
to:  *pogY)) 

(goal 

(action:  move 
object:  "parti 
to:  *pegY) ) ) 

{  This  production  moves  a  disk.  It  assumes  that  all  single  disks  can  be 
moved.} 

(p  move-disk 
action:  move 
object:  »obJectl 
to:  opegA 
tests: 

(on  «objectl  «pegB) 

(Isa  *obJectl  single-disk) 

*•> 

(•remove  1) 

(on  "objectl  »pegA) 

(•pop  success)) 
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{  This  production  Is  optional.  It  makes  sure  that  we  are  not  moving 

a  disk  which  Is  not  the  smallest  on  the  peg.  Note  that  conflict  resolution 
will  favor  this  production  over  the  simple  move-disk  If  a  move  Is  wrong.) 

(p  cannot-move-dlsk 
action:  move 
object:  -objectl 
to:  «pegA 
tests: 

(on  -objectl  -pegB) 

(Isa  -objectl  single-disk) 

(on  -obJect2  -pegB) 

(smal ler-than  -obJect2  -objectl) 

(•pop  failure)) 

{  This  production  Is  optional  also.  It  makes  sure  that  we  are  not  placing 
a  disk  on  a  peg  which  already  has  a  disk  on  It  which  Is  larger.  This 
production  will  also  ba  preffered  In  conflict  resolution  If  a  move  Is 
Illegal.  } 

(p  Illegal-move 
action:  move 
object:  -objectl 
to:  -pegY 
tests : 

(on  -objectl  -pegX) 

(Isa  -objectl  single-disk) 

(on  -0bject2  -pegY) 

(smallor-than  -obJect2  -objectl) 

(•pop  failure)) 

{  The  top  goal  Is  to  move  pyramld-A  from  where  It  Is  to  peg-3.  } 

( setgoal 

'(action:  move 
object:  pyramld-A 
to:  peg-3)) 

{  The  facts  about  pegs,  disks,  and  pyramids  are  encoded  In  working  memory. 

The  Initial  situation  Is  also  coded  In  working  memory,  though  GRAPES  allows 
one  to  access  auxiliary  memories  on  the  left  and  right  hand  sides  of 
productions  using  LISP  functions.  } 

(setwm  '((has-part  pyramld-A  pyramld-B  dlsk-A) 

(has-part  pyramld-B  dlsk-C  disk-B) 

(Isa  peg-1  peg) 

(Isa  peg-2  peg) 

(Isa  peg-3  peg) 

(Isa  dlsk-A  single-disk) 

(Isa  dlsk-B  single-disk) 

(Isa  dlsk-C  single-disk) 

(smaller-than  dlsk-B  dlsk-A) 

(smaller-than  dlsk-C  dlsk-A) 

(smaller-than  pyramld-B  dlsk-A) 

(smaller-than  pyramld-B  pyramld-A) 

(smallor-than  dlsk-C  pyramld-B) 

(smaller-than  dlsk-C  disk-8) 

(on  dlsk-A  peg-1) 

(on  dlsk-B  peg-1) 

(on  dlsk-C  peg-1))) 
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Appendix  VI 
A  Sample  Run 

I  Ins  is  an  actual  GRAPHS  photo  tile  made  with  the  "photo"  command.  The  productions  "slurp"cd  are 
listed  in  appendix  4. 

PHO  TO  recording  initiated:  ghanoi.log 


[*]  (slurp  ghanoi)  ;  The  default  extension  is  .grp 


tnakc-subproblcms 
mm  e-disk 
cannot-movc-disk 
illegal-move 

***  Top  goal  defined.  *** 

***  Working  memory  defined.  *** 

Production  Environment  Defined. 

1*1  pptopgoal  ;  Print  the  top  goal 
top-goal 
action:  move 
object:  pyramid-A 
to:  peg-3 
endgoal 

[*]  ppwm  ;  Print  working  memory 
WORKING  MEMORY: 

(has-part  pyramid-A  pyramid-B  disk-A) 
(has-part  pyramid-B  disk-C  disk-B) 

(isa  peg-1  peg) 

(isa  peg-2  peg) 

(isa  peg-3  peg) 

(isa  disk-A  single-disk) 

(isa  disk-B  single-disk) 

(isa  disk-C  single-disk) 

(smallcr-than  disk-B  disk-A) 
(smallcr-thon  disk-C  disk-A) 
(smallcr-thar.  pyramid-B  disk-A) 
(smallcr-than  pyramid-B  pyramid-A) 
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(sm.iller-ih.m  disk-C  pyramid- II) 
(smaller-than  disk-C  disk  -  li) 

(on  disk-A  peg- 1 ) 

(on  disk  -  B  peg-1) 

(on  disk-C  peg-1) 

HND 


(*1  ptracc  :  Trace  productions  tiring 

make-subproblcms 

move-disk 

eannot-move-disk 

illegal-move 

[*]  gtracc  :  Trace  goal  information 
move 

[*]  start  ;  Start  the  system.  The  top  goal  and  current  working  memory 
;  are  the  defaults. 


top-goal 
.  action:  move 
.  object:  pyramid-A 
to:  peg- 3 
endGoal 

|  1)  make-subproblcms. 

|  .  TESTS: 

|  .  (has-part  pyramid-A  pyramid-B  disk-A) 
|  .  (on  disk-A  peg-1) 

|  .  (smallcr-than  pyramid-B  disk-A) 

|  .  (isa  peg-2  peg) 

|  .  (*not  (‘equal  peg-2  peg-1)) 

|.  (‘not  (‘equal  peg-2  peg- 3)) 

|  .  SUBGOALS  created: 

I  •  (goal-1 
|  .  (action:  move 

|  .  object:  pyramid-B 

I  ■  to:  peg-2)) 

I  .  (goal-2 
|  .  (action:  move 

|  .  object:  disk-A 

|  .  to:  peg-3) ) 


.  (goal-3 

(action:  move 
object:  pyramid- 13 
to:  peg- 3) ) 
endl’roduction 


goal-1 

.  action:  move 
object:  pyramid-11 
.  to:  peg- 2 
endCoal 

|  2)  makc-subproblcms. 

|  .  1'HSTS: 

|  .  (has-parc  pyramid-))  disk-C  disk-B) 

|  .  (on  disk-13  peg-1) 

|  .  (smallcr-than  disk-C  disk-B) 

|.  (isa  peg-3  peg) 

|.  (*not  (’equal  peg-3  peg- 1)) 

|.  (*not(*cqual  peg-3  peg- 2)) 

|  .  SU13GOA1.S  created: 

|  .  (goal-4 

|  .  (action:  move 

|  .  object:  disk-C 

|  .  to:  peg-3) ) 

I  ■  (goal-5 

|  .  (action:  move 

!  .  object:  disk-B 

|  .  to:  peg- 2) ) 

|  .  (goal-6 

|  .  (action:  move 

|  .  object:  disk-C 

|  .  to:  peg-2) ) 

|  endProduction 


goal-4 

.  action:  move 
.  object:  disk-C 
.  to:  peg-3 
endGoal 
|  3)  move-disk. 
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|  .  I  I  S  I  S: 

|  .  (on  disk -C  peg- 1) 

|  .  (isa  disk-C  single-disk) 

|  .  INSER  1  1  1)  into  wm: 

|  .  (on  disk-C  peg-3) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-C  peg-1) 

|  cndProduction 
Goal  successful. 

goal-5 

.  action:  move 
object:  disk-B 
.  to:  peg- 2 
cndGoai 
|  4)  move-disk. 

|  .  TESTS: 

|  .  (on  disk-13  peg- 1) 

|  .  (isa  disk-B  single-disk) 

|  .  INSERTED  into  wm: 

|  .  (on  disk-B  peg- 2) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-B  peg- 1) 

|  cndProduction 
Goal  successful. 

goal-6 

.  action:  move 
.  object:  disk-C 
.  to:  pcg-2 
endGoal 
|  5)  move-disk. 

|  .  TESTS: 

|  .  (on  disk-C  pcg-3) 

|.  (isa  disk-C  single-disk) 
|  .  INSERTED  into  wm: 

|  .  (on  disk-C  pcg-2) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-C  peg- 3) 

|  cndProduction 
Goal  successful. 

Goal  successful. 


goal-2 

.  action:  move 
object:  disk -A 
to:  peg- 3 
endGoal 
|  6)  move-disk. 

|  .  TESTS: 

|  .  (on  disk- A  peg- 1) 

|  .  (isa  disk-A  single-disk) 

|  .  INSERTED  into  wm: 

|  .  (on  disk-A  pcg-3) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-A  peg-  L) 

|  cndProduction 
Goal  successful. 

goal-3 

.  action:  move 
object:  pyramid-B 
to:  pcg-3 
endGoal 

|  7)  makc-subproblems. 

|  .  TESTS: 

|  .  (has-part  pyramid-B  disk-C  disk-B) 

|  .  (on  disk-B  peg-2) 

|.  (smallcr-than  disk-C  disk-B) 

|  .  (isa  peg-1  peg) 

|.  ('not  ('equal  pcg-1  pcg-2)) 

|.  (*not  ('equal  pcg-1  peg-3)) 

|  .  SUBGOALS  created: 

I  .  (goal-7 

|  .  (action:  move 

|  .  object:  disk-C 

|.  to:  pcg-1)) 

|  .  (goal-8 

|  .  (action:  move 

|  .  object:  disk-B 

|.  to:  pcg-3)) 

I  •  (goal-9 

|  .  (action:  move 

|  .  object:  disk-C 

|  .  to:  peg-3) ) 

|  cndProduction 


goal-7 

.  action:  move 
object:  disk-C 
to:  peg-1 
cndGoal 
|  8)  move-disk. 

|  .  TESTS: 

|  .  (tin  disk-C  peg- 2) 

|  .  (isa  disk-C  single-disk) 
|  .  INS1-IR TED  into  wm: 

|  .  (on  disk-C  pcg-l) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-C  pcg-2) 

|  cndProduction 
Goal  successful. 

goal-8 

.  action:  move 
object:  disk-B 
to:  peg- 3 
cndGoal 
|  9)  move-disk. 

|  .  TESTS: 

|  .  (on  disk-B  pcg-2) 

|  .  (isa  disk-B  single-disk) 
|  .  INSERTED  into  wm: 

|  .  (on  disk-B  pcg-3) 

|  .  REMOVED  from  wm: 

|  .  (on  disk-B  pcg-2) 

|  cndProduction 
Goal  successful.  , 

goal-9 

.  action:  move 
object:  disk-C 
to:  pcg-3 
cndGoal 
(  10)  move-disk. 

|  .  TESTS: 

|  .  (on  disk-C  peg- 1) 

(  .  (isa  disk-C  single-disk) 
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|  |  |  .  INSI'U  I  I  D  into  wm: 

|||.  (on  disk-C  pcg-J) 

|||.  REMOVED  from  wm: 

|||.  (on  disk-C  pcg-1) 

|  |  |  endProduction 
|  |  Goal  successful. 

|  Goal  successful. 

Goal  successful. 

HN1>-  Top  Goal  Successful. 

[*] ,  pwm 

WORKING  MHMORY: 

(has-part  pyramid- A  pyramid- B  disk-A) 

(has-part  pyramid-!}  disk-C  disk-13) 

(isa  pcg-1  peg) 

(isa  peg- 2  peg) 

(isa  peg- 3  peg) 

(isa  disk-A  single-disk) 

(isa  disk-B  single-disk) 

(isa  disk-C  single-disk) 

(smallcr-than  disk- 13  disk-A) 

(smallcr-thau  disk-C  disk-A) 

(smallcr-than  pyramid-13  disk-A) 

(smallcr-than  pyramid-13  pyramid-A) 

(smallcr-than  disk-C  pyramid-13) 

(smallcr-than  disk-C  disk-13) 

(on  disk-A  pcg-3) 

(on  disk-B  pcg-3) 

(on  disk-C  pcg-3) 

END 

[*]  unphoto  ;  This  execution  was  recorded  using  GRAPES  photo  package 


PHOTO  recording  terminated. 


Appendix  VII 
The  LISP  Module 

The  GR.API-'S  LISP  module  is  .1  set  ol"  top-level  and  user  functions  which  are  loaded  automatically  when 
the  command  (mode  lisp)  is  issued  while  at  die  top-level.  The  LISP  package  defines  a  set  of  convenient 
functions  for  modelling  expert  and  novice  I.ISP  programmers.  Ihis  module  could  also  be  used  to  form  die 
basis  for  an  automatic  LISP  programming  system. 

When  the  package  is  loaded,  all  goals  with  an  action  to  write  arc  examined.  These  goals  should  have  the 
name  of  the  function  being  written  as  the  value  of  a  function  attribute,  the  argument  list  as  the  value  of  a  args 
attribute,  and  an  atom  representing  the  output  relation  under  a  output  attribute.  All  goals  in  Lh is  format  will 
produce  a  Fran/.  LISP  lambda  definition.  A  <?>  will  represent  the  code  for  the  body  of  the  function. 


VII. 1 .  Top-level  commands 

ltracc 

form:  (ltracc) 
arguments:  none 

synopsis:  Starts  tracing  LISP  code  as  it  is  being  written  by  the  system. 

luntrace 

form:  (luntrace) 
arguments:  none 

synopsis:  Stops  tracing  all  functions  currently  being  written  by  the  system, 
savef 

form:  (savef file) 

arguments:  file:  the  name  of  a  legal  output  file, 
synopsis:  Saves  in  file  all  function  definitions  which  were 
defined  by  the  system. 

showtable 

form:  (showtable) 
arguments:  none 

synopsis:  Pretty-prints  the  contents  of  the  LISP  module's  symbol  table. 
All  function  names,  arguments,  and  local  variables  for  each 
function  currently  defined  arc  shown.  Also,  each  symbol  is 
displayed  along  with  its  expansion. 


PrtECEDlNQ  PAuS  BLANK -NOT  FI  i>SL 
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VII. 2.  User  Functions 

I. eft- 1  land  Side  Functions 
*uscp 

form:  (*uscp  name  template) 

arguments:  name:  (he  name  of  a  function  currently  defined. 

template:  A  list  consisting  of  a  template  name  followed 
by  its  arguments^4. 

synopsis:  Returns  "t"  if  function  name  uses  template  for  its 
body  definition.  Otherwise  it  returns  "nil". 


’writep 

form:  (’writep  term  method) 

arguments:  term:  A  I  .ISP  atom  which  has  an  entry  in  die  symbol  table. 
method:  An  expression. 

synopsis:  Returns  "t"  if  term  is  written  in  terms  of  method  in  the 
symbol  table. 


’Ivarp 

form:  (’Karp  vars [goo/1) 

arguments:  vars:  The  name  of  a  local  variable,  ora  list  of  local 
variables. 

goal:  A  goal  which  specifics  where  to  begin  the  search 
for  the  function  with  the  specified  local  variables. 
This  goal  defaults  to  the  current  goal, 
synopsis:  Returns  "t"  if  run  arc  all  members  of  the  local  variable 
list  of  the  function  found. 


’gvarp 

form:  (’gvarp  van  (gou/)) 

arguments:  vars:  The  name  of  a  global  variable,  or  a  list  of  global 
variables. 

goal:  A  goal  which  specifics  where  to  begin  the  search 
for  the  function  with  the  specified  local  variables. 

This  goal  defaults  to  the  current  goal, 
synopsis:  Returns  "t"  if  van  are  all  global  variables  associated  with 
the  function  found. 

Right-hand  Side  Functions 

’define 
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form:  |  ‘define  name) 

arguments:  name:  \n  atom  representing  .1  function  name. 

sv  nopsis:  1  Vela  res  name  to  be  a  I  I S I  ’  function,  signalling 

that  H  is  gome  to  be  written  In  the  production  set.  I  his  function  is 

usuullv  used  to  define  helping  functions  and  functions  which  are 

subproblems. 

‘undetine 

form:  (‘undeline  name) 

arguments:  name:  liic  name  of  a  currently  defined  function. 
s>  nopsis:  Removes  a  function  name  from  the  list  of  functions 
currcntU  being  w  ritten.  Equivalent  to  erasing  the 
function  definition  from  the  symbol  tabic. 


‘use 

form:  (‘use  name  template) 

arguments:  name:  !  he  name  of  a  function  currently  defined. 

template:  A  list  containing  a  template  followed  by  its  arguments, 
synopsis:  Uses  the  given  template  to  write  the  body  of  name.  A  list 
of  templates  is  given  in  the  next  section. 


‘examine 

form:  (‘examine  e.xpr) 
arguments:  e.xpr:  A  I. ISP  expression. 

synopsis:  Looks  at  e.xpr  and  determines  its  properties,  ‘mapstorc 

can  be  used  to  store  each  property  as  a  list  in  working  memory. 
The  properties  currently  examined  arc:  member,  first,  end.  list, 
atom,  dotted-pair,  and  length. 


*cval 

form:  (*eval  test-name  e.xpr) 
arguments:  test-name:  An  unbound  variable. 
expr:  A  LISP  expression. 

synopsis:  Evaluates  e.xpr  and  returns  a  list  describing  the 

result  of  the  evaluation.  If  the  evaluation  yields  a  result, 

the  list:  ( resuit-of  test-name  is  =  result).  If  the 

evaluation  results  in  an  error,  one  of  tire  following  working-memory 

elements  is  returned: 

Error  Result 


1.  Unbound  variable  (rcsult-of  test-name  is 

lisp-error  unbound-variable) 

2.  Undefined-function  (rcsult-of  rest- name  is 
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lisp-error  undolincdTunction) 

.1.  Had  aig  in  car  (rosnli-of  test-name  is  lisp-error 
h.idTunciionarg) 

4.  Had  are  to  signp  (roMilt-of  test-name  is  lisp-error 

had-funciion-arg) 

5.  Other  errors  ( result-of  test-n ante  is  lisp-error 

misc-error) 


‘write 

form:  ('write  term  method) 

arguments:  term:  \  I. ISP  atom  in  the  symbol  table 

method:  An  expression  representing  the  expansion  of  term. 
synopsis:  Makes  a  new  entry  in  the  symbol  table.  Generally,  term 

will  will  be  a  symbol  which  has  no  concrete  code  associated  with  it. 
*w  rite  w  ill  expand  term  into  the  more  concrete  terms  given 
by  method.  In  tins  way.  the  body  of  a  I.1SP  function  is  written 
in  terms  of  various  symbols  representing  major  parts  its  body.  These 
pieces  arc  in  turn  written  in  terms  of  other  pieces,  and  so  on. 

These  pieces  are  often  intimately  linked  to  the  goal  structure. 

Sec  the  sample  function  and  symbol  table  for  tine  Powerset  function. 


*lvar 

form;  (’tear  vars [goal]) 

arguments:  vars:  ’The  name  of  a  local  variable,  or  a  list  of  names 
of  local  variables. 

goal:  A  goal  which  specifics  where  to  begin  tine  search 

for  the  function  which  will  acquire  the  new  local  variables, 
defaults  to  the  current  goal. 

synopsis:  Creates  any  number  of  local  variables  for  a  function.  The 
function  is  retrieved  by  searching  the  actions  of  successive 
supcrgoals  of  goal  for  an  action  to  write.  If  such  a  goal 
is  found,  then  the  function  name  can  be  found  as  the  value  of 
the  function  attribute. 


•gvar 

form:  (*gvar  vars  [goo/]) 

arguments;  vars:  The  name  of  a  global  variable,  or  a  list  of 
names  of  global  variables. 

goal:  A  goal  which  specifies  where  to  begin  the  search  for 
the  function  which  will  use  die  global  variables. 

Defaults  to  the  current  goal. 

synopsis:  Creates  any  number  of  global  variables  to  be  used  in  a  function. 
The  function  is  found  in  a  search  identical  to  that  done  when 
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adding  luv_.il  variables  U)  .1  function'''. 

Right-hand  or  I  cfl-liaml  Side  1- unctions 

•gc'.gv  ars 

hum:  I  Veil'. .IIS  [-: ■://  [  - 

arguments:  g< *.//.•  \  goal  which  specifies  where  so  begin  die  search  tor 
the  function  which  will  use  the  global  variables. 

1  he  goal  defaults  to  the  current  goal. 

-  •■ar.::u:  An  unbound  'unable. 

synopsis:  Hinds  =  variist  to  the  list  of  global  variables  associated 
with  the  function  found. 


•rgvars 

form:  ( *rg\  ars  [ -. artist  (gn<i/]|) 

arguments:  variist:  1'he  name  of  a  global  variable,  or  a  list  of 
names  of  global  variables. 

goal:  A  goal  which  specifies  where  to  begin  die  search  for 
the  function  which  lias  the  global  variables. 

Defaults  to  the  current  goal. 

svnopsis:  Removes  die  global  variables  in  variist  from  tire  list  of 
global  variables  associated  with  die  function  found. 


form:  (“gctlvars  [gou/fvji/fs/]]) 

arguments:  goal:  \  goal  which  specifics  where  to  begin  the  search  for 
the  function  which  has  die  local  variables. 

The  goal  defaults  to  the  current  goal. 

=  variist:  An  unbound  variable. 

synopsis:  Rinds  =  variist  to  die  local  variable  list  of  the  function 
found. 


’rlvars 

form:  (’rlvars  [goal[varlist\\) 

arguments:  goal:  A  goal  which  specifics  where  to  begin  die  search  for 
die  function  which  has  die  local  variables. 

The  goal  defaults  to  the  current  goal. 

=  variist:  An  unbound  variable. 

synopsis:  Removes  the  local  variables  in  variist  from  function's 
local  variable  list. 
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see  *tvar  command 


•l'u  nainn 

form:  ( * t\i nclu 'll  #'.-■»»»«■  (i;i -i/'l) 

arguments:  \n  unbound  variable. 

g.  ■<//.•  \  goal  which  '.panics  whoic  to  Ivan  :lie  mmicIi  for 
tile  function  name. 

i'.i'I'ms:  Return-'  the  name  of  the  goal  reteieiiceJ  by  -,;i \ii.  1  lie 
referencing  algorithm  lucks  at  successive  Mipcrgoals  of 
goal.  looking  for  a  goal  whose  action  is  "write".  If 
such  .i  goal  is  found,  the  value  of  its  junction:  attribute 
is  bound  to  -  name. 

•lisp 

form:  ( “lisp  c.xpr) 

arguments:  *i<expr:>  Ain  expression. 

sy  nopsis:  Returns  "t"  if  c.xpr  is  1  ISP  code.  It  must  he  mi.t.a  number, 
a  string,  or  a  list  with  a  function  call  as  its  first  element. 

I  ISP  templates 
iteration 

form:  (‘’[iteration  list  repeal ) 

arguments:  list:  A  list  to  map  over.  taking  successive  edr's. 

repeal:  A  piece  of  code  representing  the  operation 
to  he  performed  on  each  iteration  through  the  loop. 

synopsis:  This  template  represents  a  schematic  way  to  do 
an  iterative  procedure  in  I. ISP.  The  basic  structure 
of  an  iterative  process  is  often  the  same.  This  code 
template  captures  die  similarities  between  most  of  the 
iterative  procedures  used  in  basic  I. ISP,  leaving  the 
differences  to  be  filled  in  as  variables. 

It  creates  a  local  variable  to  hold  the 

result  list.  Whenever  a  local  variable  is  used,  a  LISP 

prog  structure  is  automatically  created. 

result: 

(prog  (it-var) 

loop  (cond((not  list)  (return  it-var))) 

(setq  it-var  (appendl  it-var  repeat)) 

(setq  list  (edr  list)) 

(go  loop)) 

%cdr-  recursion 

form:  (°ocdr- recursion  test  term  result) 

arguments:  test:  A  test  which  will  terminate  the  recursion. 
term:  An  action  for  the  terminating  condition  of  the 
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recursion. 

result:  I  he  recursive  step. 

synopsis:  I  his  tempi. ite  ropicscius  a  schematic  way  to  do  a  recursive 
procedure  using  the  method  ot'cdr  or  tail  recursion, 
result: 

(condunot  mi) term) 

(t  resuit)) 

rc  fran/-lamhda- function 

form:  (rrlran/-lambda-t'unction  name  arghst  body) 
arguments:  name:  \  function  name. 

ar^hst:  \  list  of  arguments  tor  the  function. 
body:  I  lie  hod>  of  the  function. 

synopsis:  Creates  a  I'ran/ 1  ISP  lambda  defmtion.  This  template  is 
used  by  die  I  ISP  module  to  define  functions  specified 
by  goals  with  the  action  "write". 

result: 

(def  name 

(lambda  (arglist)  / 

body)) 

I 

^ceode-in  loop 

form:  (“kudo- in- loop  e.xpr)  i 

arguments:  e.xpr:  A  piece  ofl.ISP code. 

synopsis:  Creates  a  looping  structure  with  e.xpr  as  the  loop 

body.  Any  local  variables  which  are  used  with  be  placed  as 
arguments  to  the  prog  surrounding  the  loop. 

result: 

(prog  <local-variablcs> 
loop  expr 
(go  loop)) 

VII. 3.  A  Sample  Symbol  Table 

The  symbol  table  provides  a  way  of  representing  and  manipulating  the  I. ISP  code  written  by  GRAPHS. 

Each  symbol  is  stored  and  then  expanded  into  the  code  found  in  the  function  definitions. 


These  two  functions: 
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(def  powerset 
( lambda  (1 istl) 

( cond  ( ( no t  1  istl)  '(nil)) 

(t 

(append  (powerset  (cdr  1  i s 1 1 ) ) 

(Sfunctionl  (car  1  istl)  (powerset  (cdr  1  i  s 1 1 ))))))) ) 

(def  Qfunctionl 

(lambda  (Qeltl  Sresultl) 

(cond  ((not  Sresultl)  ’nil) 

(t 

(cons  (cons  Seltl  (car  Sresultl)) 

(Sfunctionl  Seltl  (cdr  Sresultl))))))) 


were  produced  from  die  following  s>  mbol  table: 


function 

args  body  local  vars 

powerset 

(Hstl)  SfBodyl  none. 

Sfunctionl 

(Seltl  Sresultl)  SfBody2  none. 

symbol 

expands  to 

SfBodyl 

(Xcdr-recurs Ion  llstl  Sterm-condl  Hst2) 

1 1st2 

(append  Sresultl  Sterml) 

Sresul tl 

(powerset  8result2) 

Sresul t2 

(cdr  llstl) 

Sterml 

(Sfunctionl  Seltl  Sresultl) 

SfSady2 

(Xcdr-recurslon  Sresultl  Sterm-cond2  8term2) 

Seltl 

(car  llstl) 

Sterm2 

(cons  Sterm3  Sresult3) 

Sterm3 

(cons  Seltl  8e1t2) 

Sel  t2 

(car  Sresultl) 

Sresul t3 

(Sfunctionl  Seltl  Sresult*) 

8result4 

(cdr  Sresultl) 

8term-cond2 

nil 

Sterm-condl 

(nil) 
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Appendix  VIII 

Formal  Production  Specification 

The  following  is  .1  tbnn.ii  syntactic  specification  for  GRAPHS  productions, 
given  in  a  modified  Backus-Naur  form: 

production  ::  =  "(p  "  p-nainc  left-side "  =  =>  "  right-side  "  )" 
p-name  ::  =  ATOM 

left-side  ::  =  goal-context  /  goal-context  test-part 

goal-context  action-parameter  /  action-parameter  other-parameters 

action-parameter  ::=  "action:  "  CONSTANT 

other-parameters ::  =  parameter  /  parameter  other-parameters 

parameter  ::=  attribute  value 

attribute  ::=  labelled-atom 

value  ::  =  pattern 

test-part  "tests:  "  Ihs-tcsts 

Ihs-tcsts  ::  =  lhs-clt  /  Ihs-elt  Ihs-tcsts 

Ihs-clt ::  =  lhs-tcst-typc  /  match-type  lhs-tcst-typc 

match-type  ::  =  ”  +  "  /  "-  "  /  ”?  " 

lhs-tcst-typc  ::  =  wm-test  /  goal-test  /  function-call 

wm-test  ::=  list-pattern 

function-call ::  =  "(  "  function-body  "  )” 

function-body  ::  =  function-name  /  function-name  function-args 

fiinction-args ::  =  pattern-cits 

goal-test ::  =  "(  ”  goal-header  goal-body  "  )" 

goal-header ::  =  goal-type  /  subgoal-type  /  supcrgoal-typc 

goal-type  ::  =  "goal  "  /  "goal  "  g-name 

subgoal-typc  ::  =  "subgoal  "  /  "subgoal  "  g-args 

supcrgoal-typc  ::  =  "supergoal  "  /  "supergoal  ”  g-args 

g-args  ::  =  g-namc  /  of-goal  g-name 

g-name  ::  =  CONSTANT  /  variable  /  function-call 

of-goal ::  =  CONSTAN  T  /  variable  /  function-call 

goal-body  ::  =  g-parameters  /  g-parameters  ncstcd-goal-spccs 

g-parameters  ::=  ”(  "  parameter-list " )" 

parameter-list ::  =  action-parameter  otlicr-paramctcrs  /  other-parameters 
ncstcd-goal-spccs  ::  =  goal-test  /  goal-test  ncstcd-goal-spccs 

right-side  ::  =  rhs-elt  /  rhs-clt  right-side 

rhs-elt ::  =  wm-insertion  /  goal-insertion  /  function-call 
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win-insertion  wm-tcst 

goal-insertion  goal-test 

pattern  ::=  pattern-eit  /  list-pattern 

pattern-ell ::  =  CONS  I'ANT  /  variable  /  segment-var  /  function-call 

pattern  -elts  ::  =  pattern  /  pattern  pattern-elts 

list-pattern  ::  =  "( "  pattern-elts  "  )" 

labelled-atom  ::  =  (CONSTANT <>  "action")  & 

variable  ::=  "  =  "&  A  TOM 

segment-var ::  =  "$"  &  ATOM 

function-name  ::  =  &  ATOM 

ATOM  is  any  LISP  atom,  except  "nil". 

CONSTANT  is  any  L.1SP  atom  whose  first  character  is  not "  =  ”,  "$",  or  "* 


CMU/Anderson  September  14,  1982 


Page  1 


Mon  Govt 


1  DR.  GERSHOM  WELTMAN 
PERCEPTRONICS  INC. 

6271  VARIEL  AVE. 

WOODLAND  HILLS,  CA  91367 

1  Dr.  Keith  T.  Wescourt 

Information  Sciences  Dept. 
The  Rand  Corporation 
1700  Main  St. 

Santa  Monica,  CA  90406 

1  DR.  SUSAN  E.  WHITELY 
PSYCHOLOGY  DEPARTMENT 
UNIVERSITY  OF  KANSAS 
LAWRENCE,  KANSAS  66044 

1  Dr.  Christopher  Wickens 
Department  of  Psychology 
University  of  Illinois 
Champaign,  IL  61820 

1  Frank  R.  Yekovich 
School  of  Education 
Catholic  University 


CMU/Anderson 


September  14,  1982 


Page  1 


Navy 


1  Dr.  Robert  Breaux 
Code  N-711 
NAVTRAEQUIPCEN 
Orlando,  FL  32813 

1  CDR  Mike  Curran 

Office  of  Naval  Research 
800  N.  Quincy  St. 

Code  270 

Arlington,  VA  22217 

1  DR.  PAT  FEDERICO 

NAVY  PERSONNEL  RAD  CENTER 
SAN  DIEGO,  CA  92152 

1  Dr .  John  Ford 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

1  LT  Steven  D.  Harris,  MSC.  USN 
Code  6021 

Naval  Air  Development  Center 
Warminster,  Pennsylvania  18974 

1  Dr.  Jim  Hollan 
Code  304 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

1  CDR  Charles  W.  Hutchins 

Naval  Air  Systems  Command  Hq 
AIR-340F 
Navy  Department 
Washington,  DC  20361 

1  Dr.  Norman  J.  Kerr 

Chief  of  Naval  Technical  Training 
Naval  Air  Station  Memphis  (75) 
Millington,  TN  38054 

1  Dr.  William  L.  Maloy 

Principal  Civilian  Advisor  for 
Education  and  Training 
Naval  Training  Command,  Code  00A 
Pensacola,  FL  32508 


Navy 


1  CAPT  Richard  L.  Martin,  USN 
Prospective  Commanding  Officer 
USS  Carl  Vinson  (CVN-70) 

Newport  News  Shipbuilding  and  Drydock  Co 
Newport  News,  VA  23607 

1  Dr  William  Montague 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

1  Ted  M.  I.  Yellen 

Technical  Information  Office,  Code  201 
NAVY  PERSONNEL  RAD  CENTER 
SAN  DIEGO,  CA  92152 

1  Library,  Code  P201L 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

1  Technical  Director 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

6  Commanding  Officer 

Naval  Research  Laboratory 
Code  2627 

Washington,  DC  20390 

1  Psychologist 

ONR  Branch  Office 
Bldg  114,  Section  D 
666  Summer  Street 
Boston,  MA  02210 

1  Office  of  Naval  Research 
Code  437 

800  N.  Quincy  SStreet 
Arlington,  VA  22217 

5  Personnel  A  Training  Research  Programs 
(Code  458) 

Office  of  Naval  Research 
Arlington,  VA  22217 

1  Psychologist 

ONR  Branch  Office 
1030  East  Green  Street 
Pasadena,  CA  91101 
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Navy 


Navy 


Mr  John  H.  Wolfe 
Code  P310 

U.  S.  Navy  Personnel  Research  and 
Development  Center 
San  Diego,  CA  92152 


Selection  and  Training  Research  Division 
Human  Performance  Sciences  Dept. 

Naval  Aerospace  Medical  Research  Laborat 
Pensacola,  FL  32508 

1  Dr.  Gary  Poock 

Operations  Research  Department 
Code  55PK 

Naval  Postgraduate  School 
Monterey,  CA  93940 

1  Dr.  Worth  Scanland,  Director 

Research,  Development,  Test  &  Evaluation 
N-5 

Naval  Education  and  Training  Command 
NAS,  Pensacola,  FL  32508 

1  Dr.  Alfred  F.  Smode 

Training  Analysis  &  Evaluation  Group 
(TAEG) 

Dept,  of  the  Navy 
Orlando,  FL  32813 

1  Dr.  Richard  Sorensen 

Navy  Personnel  R&D  Center 
San  Diego,  CA  92152 

1  Roger  Weissinger-Baylon 

Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Monterey,  CA  93940 

1  Dr.  Robert  Wisher 
Code  309 

Navy  Personnel  R&D  Center 
San  Diego,  CA  92152 


1  Special  Asst,  for  Education  and  1 

Training  (0P-01E) 

Rm.  2705  Arlington  Annex 
Washington,  DC  20370 

1  Office  of  the  Chief  of  Naval  Operations 
Research  Development  &  Studies  Branch 
(0P-1 15) 

Washington,  DC  20350 
1  LT  Frank  C.  Petho,  MSC,  USN  (Ph.D) 
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Array  Air  Force 


1  Technical  Director  1  Dr.  Earl  A.  Alluisi 

U.  S.  Army  Research  Institute  for  the  HQ,  AFHRL  (AFSC) 

Behavioral  and  Social  Sciences  Brooks  AFB,  IX  78235 

5001  Eisenhower  Avenue 

Alexandria,  VA  22333  1  Dr.  Alfred  R.  Fregly 

AFOSR/NL,  Bldg.  410] 

1  Mr.  James  Baker  Bolling  AFB 

Systems  Manning  Technical  Area  Washington,  DC  20332 

Army  Research  Institute 

5001  Eisenhower  Ave.  1  Dr.  Genevieve  Haddad 

Alexandria,  VA  22333  Program  Manager 

Life  Sciences  Directorate 

1  Dr.  Beatrice  J.  Farr  AFOSR 

U.  S.  Army  Research  Institute  Bolling  AFB,  DC  2033 2 

5001  Eisenhower  Avenue 

Alexandria,  VA  22333  2  3700  TCHTW/TTGH  Stop  32 

Sheppard  AFB,  TX  76311 

1  DR.  FRANK  J.  HARRIS 

U.S.  ARMY  RESEARCH  INSTITUTE 
5001  EISENHOWER  AVENUE 
ALEXANDRIA,  VA  22333 

1  Dr.  Michael  Kaplan 

U.S.  ARMY  RESEARCH  INSTITUTE 
5001  EISENHOWER  AVENUE 
ALEXANDRIA,  VA  22333 

1  Dr.  Milton  S.  Katz 

Training  Technical  Area 
U.S.  Army  Research  Institute 
5001  Eisenhower  Avenue 
Alexandria,  VA  22333 

1  Dr.  Harold  F.  O’Neil,  Jr. 

Attn:  PERI-OK 
A- my  Research  Institute 
5001  Eisenhower  Avenue 
Alexandria,  VA  22? 33 

1  Dr.  Robert  Sasmor 

U.  S.  Array  Research  Institute  for  the 
Behavioral  and  Social  Sciences 
5001  Eisenhower  Avenue 
Alexandria,  VA  22 333 

1  Dr.  Joseph  Ward 

U.S.  Array  Research  Institute 
5001  Eisenhower  Avenue 
Alexandria,  VA  22 333 
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Marines 


CoastGuard 


1  Chief,  Psychological  Reserch  Branch 
U.  S.  Coast  Guard  (G-P-1 /2/TP42) 
Washington,  DC  20593 


1  Special  Assistant  for  Marine 
Corps  Matters 
Code  100M 

Office  of  Naval  Research 
800  N.  Quincy  St. 

Arlington,  VA  22217 

1  DR.  A.L.  SLAFKOSKY 

SCIENTIFIC  ADVISOR  (CODE  RD-1 ) 
HQ,  U.S.  MARINE  CORPS 
WASHINGTON,  DC  20380 


1  H.  William  Greenup 

Education  Advisor  (E031) 
Education  Center,  MCDEC 
Quantico,  VA  22134 
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Other  DoD 


Civil  Govt 


12  Defense  Technical  Information  Center 
Cameron  Station,  Bldg  5 
Alexandria,  VA  22314 
Attn:  TC 


Dr.  Paul  G.  Chapin 
Linguistics  Program 
National  Science  Foundation 
Washington,  DC  20550 


1  Military  Assistant  for  Training  and 
Personnel  Technology 

Office  of  the  Under  Secretary  of  Defense 
for  Research  A  Engineering 
Room  3D129,  The  Pentagon 
Washington,  DC  20301 

1  DARPA 

1400  Wilson  Blvd. 

Arlington,  VA  22209 


1  Dr.  Susan  Chipman 

Learning  and  Development 
National  Institute  of  Education 
1200  19th  Street  NW 
Washington,  DC  20208 

1  Dr.  John  Mays 

National  Institute  of  Education 
1200  19th  Street  NW 
Washington,  DC  20208 


1  William  J.  McLaurin 
66610  Howie  Court 
Camp  Springs,  MD  20031 

1  Dr.  Arthur  Melmed 

National  Intitute  of  Education 
1200  19th  Street  NW 
Washington,  DC  20208 

1  Dr.  Andrew  R.  Molnar 
L-ience  Education  Dev. 
and  Research 

National  Science  Foundation 
Washington,  DC  20550 


1  Dr.  Joseph  Psotka 

National  Institute  of  Education 
1200  19th  St.  NW 
Washington , DC  20208 

1  Dr.  Frank  Withrow 

U.  S.  Office  of  Education 
400  Maryland  Ave.  SW 
Washington,  DC  20202 

1  Dr,  Joseph  L.  Young,  Director 
Memory  4  Cognitive  Processes 
National  Science  Foundation 
Washington,  DC  20550 
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Non  Govt 


Non  Govt 


1  Anderson,  Thomas  H. ,  Ph.D. 

Center  for  the  Study  of  Reading 
174  Children's  Research  Center 
51  Gerty  Drive 
Champiagn,  IL  61820 

1  Dr.  John  Annett 

Department  of  Psychology 
University  of  Warwick 
Coventry  CV4  7AL 
ENGLAND 

1  1  psychological  research  unit 

Dept,  of  Defense  (Army  Office) 
Campbell  Park  Offices 
Canberra  ACT  2600,  Australia 

1  Dr.  Alan  Baddeley 

Medical  Research  Council 

Applied  Psychology  Unit 
15  Chaucer  Road 
Cambridge  CB2  2EF 
ENGLAND 

1  Dr.  Patricia  Baggett 

Department  of  Psychology 
University  of  Colorado 
Boulder,  CO  80309 

1  Dr.  Jonathan  Baron 

Dept.  of  Psychology 
University  of  Pennsylvania 
3813-15  Walnut  St.  T-3 
Philadlphia ,  PA  19104 

1  Mr  Avron  Barr 

Department  of  Computer  Science 
Stanford  University 
Stanford,  CA  94305 

1  Liaison  Scientists 

Office  of  Naval  Research, 

Branch  Office  ,  London 
Box  39  FPO  New  York  09510 

1  Dr.  Lyle  Bourne 

Department  of  Psychology 
University  of  Colorado 
Boulder,  CO  80309 


1  DR.  JOHN  F.  BROCK 

Honeywell  Systems  &  Research  Center 
(MN  17-2318) 

2600  Ridgeway  Parkway 
Minneapolis,  MN  55413 

1  Dr.  John  S.  Brown 

XEROX  Palo  Alto  Research  Center 
3333  Coyote  Road 
Palo  Alto,  CA  94304 

1  Dr.  Bruce  Buchanan 

Department  of  Computer  Science 
Stanford  University 
Stanford,  CA  94305 

1  DR.  C.  VICTOR  BUNDERSON 
WICAT  INC. 

UNIVERSITY  PLAZA,  SUITE  10 
1160  SO.  STATE  ST. 

OREM,  UT  84057 

1  Dr.  Pat  Carpenter 

Department  of  Psychology 
Carnegie-Mellon  University 
Pittsburgh,  PA  15213 

1  Dr.  John  B.  Carroll 
Psychometric  Lab 
Univ.  of  No.  Carolina 
Davie  Hall  013A 
Chapel  Hill,  NC  27514 

1  Dr.  William  Chase 

Department  of  Psychology 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 

1  Dr.  Micheline  Chi 

Learning  R  &  D  Center 
University  of  Pittsburgh 
3939  O'Hara  Street 
Pittsburgh,  PA  15213 

1  Dr.  William  Clancey 

Department  of  Computer  Science 
Stanford  University 
Stanford,  CA  94305 
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Non  Govt 


1  Dr.  Allan  M.  Collins 

Bolt  Beranek  A  Newman,  Inc. 

50  Moulton  Street 
Cambridge,  Ma  02138 

1  Dr.  Lynn  A.  Cooper 
LRDC 

University  of  Pittsburgh 
3939  O'Hara  Street 
Pittsburgh,  PA  15213 

1  Dr.  Meredith  P.  Crawford 

American  Psychological  Association 
1200  17th  Street,  N.W. 

Washington,  DC  20036 

1  Dr.  Kenneth  B.  Cross 
Anacapa  Sciences,  Inc. 

P.0.  Drawer  Q 
Santa  Barbara,  CA  93102 

1  LCOL  J.  C.  Eggenberger 

DIRECTORATE  OF  PERSONNEL  APPLIED  RESEARC 
NATIONAL  DEFENCE  HQ 
101  COLONEL  BY  DRIVE 
OTTAWA,  CANADA  K1A  0K2 

1  Dr.  Ed  Feigenbaum 

Department  of  Computer  Science 
Stanford  University 
Stanford,  CA  94305 

1  Mr.  Wallace  Feurzeig 

Bolt  Beranek  A  Newman,  Inc. 

50  Moulton  St. 

Cambridge,  MA  02138 

1  Dr.  Victor  Fields 
Dept,  of  Psychology 
Montgomery  College 
Rockville,  MD  20850 

1  Univ.  Prof.  Dr.  Gerhard  Fischer 
Liebiggasse  5/3 
A  1010  Vienna 
AUSTRIA 


Non  Govt 


1  Dr.  John  R.  Frederiksen 
Bolt  Beranek  A  Newman 
50  Moulton  Street 
Cambridge,  MA  02138 

1  Dr.  Alinda  Friedman 

Department  of  Psychology 
University  of  Alberta 
Edmonton,  Alberta 
CANADA  T6G  2E9 

1  Dr.  R.  Edward  Geiselman 
Department  of  Psychology 
University  of  California 
Los  Angeles,  CA  9002*1 

1  DR.  ROBERT  GLASER 
LRDC 

UNIVERSITY  OF  PITTSBURGH 
3939  O'HARA  STREET 
PITTSBURGH.  PA  15213 

1  Dr.  Marvin  D.  Glock 
217  Stone  Hall 
Cornell  University 
Ithaca,  NY  14853 

1  Dr.  Daniel  Gopher 

Industrial  A  Management  Engineering 
Technion-Israel  Institute  of  Technology 
Haifa 
ISRAEL  ■ 

1  DR.  JAMES  G.  GREENO 
LRDC 

UNIVERSITY  OF  PITTSBURGH 
3939  O'HARA  STREET 
PITTSBURGH,  PA  15213 

1  Dr.  Harold  Hawkins 

Department  of  Psychology 
University  of  Oregon 
Eugene  OR  97403 

1  Dr.  Barbara  Hayes-Roth 
The  Rand  Corporation 
1700  Main  Street 
Santa  Monica,  CA  90406 


-AD * A 1 22  360  GRAPES  USER'S  MANUAL ( U )  CARNEGIE -MELLON  UNIV  PITTSBURGH 
PA  OEPT  OF  PSYCHOLOGY  R  SAUERS  ET  AL .  NOV  82  ONR-82-3 
N00014-8 1 -C-0335 
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Non  Govt 


Non  Govt 


1  Dr.  Frederick  Hayes-Roth 
The  Rand  Corporation 
1700  Main  Street 
Santa  Monica,  CA  90«06 

1  Dr.  Dustin  H.  Heuston 
Wicat,  Inc. 

Box  986 

Orem.  UT  8*1057 

1  Dr.  James  R.  Hoffman 

Department  of  Psychology 
University  of  Delaware 
Newark,  DE  19711 

1  Dr.  Kristina  Hooper 
Clark  Kerr  Hall 
University  of  California 
Santa  Cruz,  CA  95060 

1  Glenda  Greenwald,  Ed. 

"Human  Intelligence  Newsletter 
P.  0.  Box  1163 
Birmingham,  MI  «8012 

1  Dr.  Earl  Hunt 

Dept,  of  Psychology 
University  of  Washington 
Seattle,  WA  98105 

1  Dr.  Ed  Hutchins 

Navy  Personnel  RAD  Center 
San  Diego,  CA  92152 

1  Dr.  Greg  Kearsley 
HumRRO 

300  N.  Washington  Street 
Alexandria,  VA  2231*1 

1  Dr.  Steven  W.  Keele 
Dept,  of  Psychology 
University  of  Oregon 
Eugene,  OR  97*103 

1  Dr.  Walter  Kintsch 

Department  of  Psychology 
University  of  Colorado 
Boulder,  CO  80302 


1  Dr.  David  Kieras 

Department  of  Psychology 
University  of  Arizona 
Tuscon.  AZ  85721 

1  Dr.  Stephen  Kosslyn 
Harvard  University 
Department  of  Psychology 
33  Kirkland  Street 
Cambridge,  MA  02138 

1  Dr.  Marcy  Lansraan 

Department  of  Psychology,  NI  25 
University  of  Washington 
Seattle,  WA  98195 

1  Dr.  Jill  Larkin 

Department  of  Psychology 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 

1  Dr.  Alan  Lesgold 
Learning  RAD  Center 
University  of  Pittsburgh 
Pittsburgh,  PA  15260 

1  Dr.  Michael  Levine 

Department  of  Educational  Psychology 
210  Education  Bldg. 

University  of  Illinois 
Champaign,  IL  61801 

1  Dr.  Mark  Miller 

TI  Computer  Science  Lab 
C/0  282*1  Winterplace  Circle 
Plano,  TX  75075 

1  Dr.  Allen  Munro 

Behavioral  Technology  Laboratories 
18**5  Elena  Ave.,  Fourth  Floor 
Redondo  Beach,  CA  90277 

1  Dr.  Donald  A  Norman 

Dept,  of  Psychology  C-009 
Univ.  of  California,  San  Diego 
La  Jolla,  CA  92093 
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Non  Govt 


1  Committee  on  Human  Factors 
JH  811 

2101  Constitution  Ave.  NW 
Washington,  DC  20418 

1  Dr.  Seymour  A.  Papert 

Massachusetts  Institute  of  Technology 
Artificial  Intelligence  Lab 
545  Technology  Square 
Cambridge,  MA  02139 

1  Dr.  James  A.  Paulson 

Portland  State  University 
P.0.  Box  751 
Portland,  OR  97207 

1  Dr.  James  W.  Pellegrino 
University  of  California, 

Santa  Barbara 
Dept,  of  Psychology 
Santa  Barabara,  CA  93106 

1  MR.  LUIGI  PETRULLO 

2431  N.  EDGEWOOD  STREET 
ARLINGTON,  VA  22207 

1  Dr.  Richard  A.  Poliak 

Director,  Special  Projects 
Minnesota  Educational  Computing  Consorti 
2520  Broadway  Drive 
St.  Paul ,MN  55113 

1  Dr.  Martha  Poison 

Department  of  Psychology 
Campus  Box  346 
University  of  Colorado 
Boulder,  CO  80309 

1  DR.  PETER  POLSON 
DEPT.  OF  PSYCHOLOGY 
UNIVERSITY  OF  COLORADO 
BOULDER,  CO  80309 

1  Dr.  Steven  E.  Poltrock 
Department  of  Psychology 
University  of  Denver 
Denver, CO  80208 


Non  Govt 


1  Dr.  Mike  Posner 

Department  of  Psychology 
University  of  Oregon 
Eugene  OR  97403 

1  MINRAT  M.  L.  RAUCH 
P  II  4 

BUNDESMINISTERIUM  DER  VERTEIDIGUNG 

P0STFACH  1328 

D-53  BONN  1,  GERMANY 

1  Dr.  Fred  Reif 
SESAME 

c/o  Physics  Department 
University  of  California 
Berkely,  CA  94720 

1  Dr.  Lauren  Resnick 
LRDC 

University  of  Pittsburgh 
3939  O'Hara  Street 
Pittsburgh,  PA  15213 

1  Mary  Riley 
LRDC 

University  of  Pittsburgh 
3939  O'Hara  Street 
Pittsburgh,  PA  15213 

1  Dr.  Andrew  M.  Rose 

American  Institutes  for  Research 
1055  Thomas  Jefferson  St.  NW 
Washington,  DC  20007 

1  Dr.  Ernst  Z.  Rothkopf 
Bell  Laboratories 
600  Mountain  Avenue 
Murray  Hill,  NJ  07974 

1  Dr.  David  Rumelhart 

Center  for  Human  Information  Processing 
Univ.  of  California,  San  Diego 
La  Jolla,  CA  92093 

1  DR.  WALTER  SCHNEIDER 
DEPT.  OF  PSYCHOLOGY 
UNIVERSITY  OF  ILLINOIS 
CHAMPAIGN,  IL  61820 
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Non  Govt 


1  Dr.  Alan  Schoenfeld 

Department  of  Mathematics 
Hamilton  College 
Clinton.  NY  13323 

1  DR.  ROBERT  J.  SEIDEL 

INSTRUCTIONAL  TECHNOLOGY  GROUP 
HUMRRO 

300  N.  WASHINGTON  ST. 

ALEXANDRIA.  VA  22314 

1  Committee  on  Cognitive  Research 
t  Dr.  Lonnie  R.  Sherrod 
Social  Science  Research  Council 
605  Third  Avenue 
New  York,  NY  10016 

1  Dr.  David  Shucard 
Brain  Sciences  Labs 

National  Jewish  Hospital  Research  Center 
National  Asthma  Center 
Denver,  CO  80206 

1  Robert  S.  Siegler 
Associate  Professor 
Carnegie-Mellon  University 
Department  of  Psychology 
Schenley  Park 
Pittsburgh.  PA  15213 

1  Dr.  Edward  E.  Smith 

Bolt  Beranek  &  Newman,  Inc. 

50  Moulton  Street 
Cambridge,  MA  02138 

1  Dr.  Robert  Smith 

Department  of  Computer  Science 

Rutgers  University 

New  Brunswick,  NJ  08903 

1  Dr .  Richard  Snow 
School  of  Education 
Stanford  University 
Stanford,  CA  94305 

1  Dr.  Kathryn  T.  Spoehr 
Pscyhology  Department 
Brown  University 
Providence,  RI  02912 


Non  Govt 


1  Dr.  Robert  Sternberg 
Dept,  of  Psychology 
Yale  University 
Box  1 1 A ,  Yale  Station 
New  Haven,  CT  06520 

1  DR.  ALBERT  STEVENS 

BOLT  BERANEK  4  NEWMAN,  INC. 

50  MOULTON  STREET 
CAMBRIDGE,  MA  02138 

1  David  E.  Stone,  Ph.D. 

Hazeltine  Corporation 
7680  Old  Springhouse  Road 
McLean,  VA  22102 

1  DR.  PATRICK  SUPPES 

INSTITUTE  FOR  MATHEMATICAL  STUDIES  IN 
THE  SOCIAL  SCIENCES 
STANFORD  UNIVERSITY 
STANFORD,  CA  94305 

1  Dr.  Kikumi  Tatsuoka 

Computer  Based  Education  Research 
Laboratory 

252  Engineering  Research  Laboratory 
University  of  Illinois 
Urbana,  IL  61801 

1  Dr.  John  Thomas 

IBM  Thomas  J.  Watson  Research  Center 
P.0.  Box  218 

Yorktown  Heights,  NY  10598 

1  DR.  PERRY  TH0RNDYKE 
THE  RAND  CORPORATION 
1700  MAIN  STREET 
SANTA  MONICA,  CA  90406 

1  Dr.  Douglas  Towne 

Univ.  of  So.  California 
Behavioral  Technology  Labs 
1845  S.  Elena  Ave. 

Redondo  Beach,  CA  90277 

1  Dr.  Benton  J.  Underwood 
Dept,  of  Psychology 
Northwestern  University 
Evanston,  IL  60201 


